Using the platform `macosx_10_13_x86_64-cp-36-cp36...
# pex
r
Using the platform
macosx_10_13_x86_64-cp-36-cp36m
, trying to resolve
bcrypt==3.1.7
(which should get
bcrypt-3.1.7-cp34-abi3-macosx_10_6_intel.whl
from pypi) does not succeed — turning the verbosity way up I see the generated tags include
abi3
only for
cp36
.
h
I’m afk but can you check PyPI to see if they release an sdist (eg a zip file) or a bdist (the wheel file itself)? If sdist, this is expected behavior
r
They do release an sdist too — but why is that expected? I set
precedence=(WheelPackage,)
since I don’t want an sdist to ever get chosen
e
I think Eric was assuming either or in his response. This does seem like a bug - do you mind filing an issue? I'll take a look this evening.
h
Ah yes agreed that this sounds like a bug. Read too quickly from phone that the bdist is made available already. Sorry for the confusion!
e
@red-television-97006 please definitely post an issue with fuller details inclusing all max verbosity output. I do not repro on linux using this CLI snippet.
Note though, to accurately repro your snippet, I find an unrelated issue that's expected as shown in the following snippet. This is because pycparser only releases an sdist (e.g.: https://pypi.org/project/pycparser/2.19/#files) and building from sdists was disallowed.
r
Hmm, it’s definitely possible the issue is with me putting all the pieces together manually, rather than using the pex CLI. I’ll file an issue though!
Oh, oof.
I was running it with Python 2, and this is the unfortunate effect of having a moderate dependency on the interpreter used to run pex 😞
e
Ouch. That though is still a bug, but of a different sort. Touched on by all these existing issues, but the 1st is most relevant: https://github.com/pantsbuild/pex/issues/658 https://github.com/pantsbuild/pex/issues/676 https://github.com/pantsbuild/pex/issues/694
r
yep yep, fortunately I’m restricting to preexisting wheels, so we don’t silently build a bad one 🙂