-
-
Notifications
You must be signed in to change notification settings - Fork 258
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
Pull in Pip fixes. #1805
Comments
The motivating slow lock resolves were reported variously through #1798 on behalf of Pants users. |
The only apparent differences found in Pip 22.2.2 are:
1 is patched and working, and 2 just leads to less efficient locking. The fall-back download-and-hash code is now used always. So 2 needs an optimization fix to 1st try to use PEP-691 json API for all locked urls without a hash before falling back to the much more expensive, download all those URLS to hash their contents. |
Ok, wiring up the PEP 691 JSON API was straight forward. This will fail for custom indexes with Bearer auth, but then we just fall back to downloading and hashing. That's slower, but still correct. This leaves 1 unit and 3 IT failing using the 22.2.2 resolver in existing tests. The unit failure is in bdist_pex and still mysterious and the 3 ITs appear to center around local project / VCS hashing and those are still otherwise mysterious as well. |
Alright, sorted. Supporting Pip 20.3.4-patched + vendored setuptools and wheel by default and Pip 22.2.2 + setuptools 65.0.0 + wheel 0.37.1 (all latest as of today), when --pip-version is requested turns out to be viable. There is 1 added line of runtime patching code to Pip and a new utility to get hashes via PEP-691 that is only engaged for new log lines emitted by new Pip. It should be the case that Pex can just add to the PipVersion enum every now and again to expand to newer Pips while retaining support for 20.3.4-patched ~indefinitely at the User's prerogative. Pex3 can just flip the default from vendored to latest supported Pip, but can continue to support users until Redhat 2.7 support goes away or some similar proxy for truly EOL. |
Noting I hit this bug using 22.2.2 in ITs sporadically: pypa/pip#11340 Users will too and that's fine. The answer will be to add a new |
This is needed to support newer Pip where fingerprints are hidden from the verbose logs Pex scrapes to build locks. The Pex fallback of downloading every artifact locked and hashing it works but is just too expensive to be the normal case. Work towards pex-tool#1805
This is needed to support newer Pip where fingerprints are hidden from the verbose logs Pex scrapes to build locks. The Pex fallback of downloading every artifact locked and hashing it works but is just too expensive to be the normal case. Work towards #1805
This change works with both current vendored Pip and Pip 22.2.2. Work towards pex-tool#1805
This is unused in this commit except in tests, but form the heart of support for newer Pip versions behind firewalls. Vendored Pip with all user Pip configuration is used to fetch newer Pip. Work towards pex-tool#1805
This change works with both current vendored Pip and Pip 22.2.2. Work towards #1805
This is unused in this commit except in tests, but forms the heart of support for newer Pip versions behind firewalls. Vendored Pip with all user Pip configuration is used to fetch newer Pip. Work towards #1805
Pex can now support multiple Pip versions and be configured to fallback as needed when newer Pip does not support a specified interpreter. Fixes pex-tool#1805
Pex can now support multiple Pip versions and be configured to fallback as needed when newer Pip does not support a specified interpreter. Fixes pex-tool#1805
Pex can now support multiple Pip versions and be configured to fallback as needed when newer Pip does not support a specified interpreter. Fixes pex-tool#1805
Pex can now support multiple Pip versions and be configured to fallback as needed when newer Pip does not support a specified interpreter. Fixes pex-tool#1805
Pex can now support multiple Pip versions and be configured to fallback as needed when newer Pip does not support a specified interpreter. Fixes #1805
Some Pex users are encountering resolve issues fixed in newer versions of Pip. Pex has been stuck on the last version of Pip to support Python 2.7 (20.3.4) in order to continue to support Python 2.7 customers. Either Pex has to cut those customers loose or it has to support both old and new Pips.
The basic scenarios:
Obviously, 1 is easiest from a maintainer perspective, but it violates an implicit contract with users. It would be better to phase out Python 2.7 / 3.5 / 3.6 / etc. support in a controlled way independent of needing to upgrade Pip to get Pip bug-fixes. As the current ~lone maintainer, I'm partial to 3 to both meet users needs and have a compact codebase to maintain. I fear 2 would lead to more complicated maintenance and missed / partial fixes.
The text was updated successfully, but these errors were encountered: