You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In particular Platform.get_supported delegates much of it's work to pep425tags / glibc which both consult a local interpreter to answer questions like:
Does the interpreter support manylinux?
Does the interpreter have abi3 support?
Concretely, if a user runs pex on OSX and supplies a --platform=linux-x86_64-cp-37-m, there is no way for pex to determine the answers to those questions for the python 3.7 the pex will eventually run on. The problem is worse for non-extended platforms; eg: --platform=linux-x86_64. In those cases we don't know if the eventual linux runtime interpreter will be d, m, mu, dmu, etc... and currently accept wheels for any of these!
We need ways to do one or all of:
Let the user specify the answers to the 1st two questions - perhaps with new pex API/CLI options.
Fail if building a pex encounters situations where these unanswered questions are important - namely pex resolves platform-specific wheels.
The text was updated successfully, but these errors were encountered:
This changes Pex to vendor pip and defer all resolution and building to it.
As part of this change some ambiguous and / or broken features were changed and APIs adjusted:
+ The egg distribution format is no longer supported.
+ The deprecated `--interpreter-cache-dir` CLI option was removed.
+ The `--cache-ttl` CLI option and `cache_ttl` resolver API argument were removed.
+ The resolver API replaced `fetchers` with a list of `indexes` and a list of `find_links` repos.
+ The resolver API removed (http) `context` which is now automatically handled.
+ The resolver API removed `precedence` which is now pip default precedence - wheels when available and not ruled out via the `--no-wheel` CLI option or `use_wheel=False` API argument.
+ The `--platform` CLI option and `platform` resolver API argument now must be full platform strings that include platform, implementation, version and abi; e.g.: `--platform=macosx-10.13-x86_64-cp-36-m`.
+ The `--manylinux` CLI option and `use_manylinux` resolver API argument were removed. Instead, to resolve manylinux wheels for a foreign platform, specify the manylinux platform to use with an explicit `--platform` CLI flag or `platform` resolver API argument; e.g.: `--platform=manylinux2010-x86_64-cp-36-m`.
Fixes#781
Additionally:
Fixes#771Fixes#763Fixes#761Fixes#735Fixes#694Fixes#660Fixes#658Fixes#642Fixes#641Fixes#628Fixes#620Fixes#614Fixes#611Fixes#608Fixes#439Fixes#415Fixes#387Fixes#315
In particular
Platform.get_supported
delegates much of it's work to pep425tags / glibc which both consult a local interpreter to answer questions like:Concretely, if a user runs pex on OSX and supplies a
--platform=linux-x86_64-cp-37-m
, there is no way for pex to determine the answers to those questions for the python 3.7 the pex will eventually run on. The problem is worse for non-extended platforms; eg:--platform=linux-x86_64
. In those cases we don't know if the eventual linux runtime interpreter will bed
,m
,mu
,dmu
, etc... and currently accept wheels for any of these!We need ways to do one or all of:
The text was updated successfully, but these errors were encountered: