-
-
Notifications
You must be signed in to change notification settings - Fork 267
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 1.4.6 builds a failing pex #550
Comments
I don't repro. I'm pretty sure this is going to hinge on a setuptools version. If you could provide more details about your environment I'd be grateful. My test:
|
This started happening for me too just now, with pex 1.4.6 (was not an issue before). I'm on OSX 10.13.6. This happens with system python (not with more modern installations). I use pyenv, but package with system python to be able to deliver my apps with just whatever system python is. I've installed
|
Pex explicitly requires Are you sure pip installation of pex doesn't issue a warning about this? Can you try installing in a fresh virtualenv or else upgrading your setuptools to 20.3 or greater? |
I package with a recent version of python, in this case 2.7.15 which has setuptools 39.0.1 My cli (https://pypi.org/project/pickley/) is universal, shebang is To clarify: pex itself isn't crashing, but the package it created doesn't work anymore with the OSX system python, I get a similar error I'm looking into an alternative way of determining version. It's just new version of pex triggered this situation. |
Setup details. Please let me know if you need anything else
|
The 1.4.6 release is definitely broken when used with Python 2.7. I created virtualenv with Python 2.7.13 and used pex-1.4.6.
Then I created a branch on the clone of my pex fork, bumped the version to 1.4.7, and did
Then the import works:
With Python 3.7 everything works with or without revert of #542.
Notice that #542 was created in December 2017 and that setuptools had a lot of bug fixes and releases itself. Perhaps those changes were not needed any more? You will know better as maintainers the exact use case where this change might be necessary. Would you consider reverting this change for users of Python 2.7 or at least looking why/how it causes issues and forward-fixing it so that we can have a new working release of pex that supports modern setuptools for the reasons I described previously in #544? |
In particular, the issues appear to be with py27 on osx. I'll take some time today to 1st tweak CI to add OSX shard(s) and get a repro with more details. Then fix forward or revert and finally release asap. |
@jsirois I am able to reproduce this on Linux consistently too. The only reason I worked on macOS last night is because I had the checkout of pex repo there and could quickly make an sdist of "1.4.7" to confirm that revert fixes the issue. In my initial testing last week I always used Linux. Here are more details in case they can help with your investigation into the root cause. I used virtualenv-16.0.0 to build a virtual environment not the venv module from Python 3 standard library. This is, again, an intentional choice because venv still doesn't have all the features of virtualenv.
With this virtualenv ready, the issue is reproducible on Linux too (I left the lines in the output that identify the interpreter on Linux and the
The revert fixes the issue on Linux too. |
@jsirois Here's the output for 1:
and the output for 2 with scrubbed paths:
|
Alright - thanks for the help. I have things figured out, but with a little smash all things, here: #553 I'll pick this back up in the morning to whittle down the minimal crisp changes needed and provide a full, satisfying explanation. |
Previously only root 3rdparty packages copied into the bootstrap were unimported leaving subpackages in-place. This could lead to a mismatch in 3rdparty package API expectations when a re-imported 3rdparty root package from the user PEX sys.path was from a different version of the 3rdparty package. Fixes pex-tool#550
Previously only root 3rdparty packages copied into the bootstrap were unimported leaving subpackages in-place. This could lead to a mismatch in 3rdparty package API expectations when a re-imported 3rdparty root package from the user PEX sys.path was from a different version of the 3rdparty package. Fixes pex-tool#550
Previously only root 3rdparty packages copied into the bootstrap were unimported leaving subpackages in-place. This could lead to a mismatch in 3rdparty package API expectations when a re-imported 3rdparty root package from the user PEX sys.path was from a different version of the 3rdparty package. Fixes pex-tool#550
Previously only root 3rdparty packages copied into the bootstrap were unimported leaving subpackages in-place. This could lead to a mismatch in 3rdparty package API expectations when a re-imported 3rdparty root package from the user PEX sys.path was from a different version of the 3rdparty package. Fixes #550
pex 1.4.6 will allow you to build a pex against the responses library, but blows up when you try to actually import it.
This works fine outside of a pex environment and with pex 1.4.5.
The text was updated successfully, but these errors were encountered: