-
-
Notifications
You must be signed in to change notification settings - Fork 289
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pex silently builds bad pexfile #498
Comments
thanks for the bug report, we'll take a look. |
confirming a regression and minimal repro on OSX:
this relates to PEP496 environmental markers support - which appear to be correctly checked at runtime, but not considered at buildtime. |
fix out here: #500 |
this should now be fixed in pex 1.4.3 - give it a shot and let me know if you hit any further issues. |
@kwlzn I am using OSX 10.13 and this issue persists with pex version 1.4.3
|
@premal I don't repro on 10.13.5 - what does fwiw:
|
@kwlzn I am running 10.13.5 on two separate boxes, both using pex 1.4.3. I can repro @premal's error on one, while everything works fine on the other. Here is my failure:
|
interesting - the mode of two different boxes with disparate results for the same command screams "environment" to me. does the failure mode improve at all if you add beyond that, it might be useful to paste the full verbose output of the working side as an apples to apples comparison here. |
|
Okay, in going through the output I noticed that my working box explicitly uses When I pass --python=/path/to/python2.7, it works where it failed before:
|
Okay, seems to be something to do with the Python version. What python does pex use by default? I assumed it was the first python on my PATH, but it seems to fail unless I explicitly pass it, e.g.:
|
I have a hunch that the variation is due to setuptools/wheel versions coming along with each interpreter. In Pant's usage of pex, we scrub the system setuptools, wheel and any other site packages and install our own. Pretty wild hunch, but I did just wade through similarly variable results upgrading pants to pex 1.4.3 from 1.3.2. The full verbose logs here help a ton and I think I have enough to setup a repro, and if successful, a fix. |
@jsirois After some further investigation (building various versions of Python from source and also installing via pyenv) I'm pretty sure it's not version dependent (I've gotten things working with 2.7.10 multiple times) but has something to do with using MacOS System Python |
@DrumMachineLearning I think @jsirois is talking about the |
FWIW I have a repro - on linux, trying to narrow it down. |
I've repro'd (one working, one not) using fresh virtualenvs on each box. Both are running setuptools 33.1.1 Interestingly enough, passing system python (i.e. |
And here's another interesting datapoint- when you force pex to build, everything works fine. On the failbox:
|
Wanted to note here - I was able to resolve the issues @premal was seeing for our users by installing python 2.7.13+ via brew (system python was 2.7.10) and resetting their venvs. |
fixed on "resetting their venvs" definitely screams "setuptools version" to me, fwiw. |
This is on OSX against
pex 1.4.2
usingpython 2.7.13
.Same command works against
pex 1.3.2
Command:
Contents of
requirements.txt
:When attempting to run
env.pex
:Interestingly, changing the
requirements.txt
to includeappnope
andipython==5.7
explicitly fixes it againstpex 1.4.2
.As mentioned, the same works either way against
pex 1.3.2
.The text was updated successfully, but these errors were encountered: