-
-
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
Fix current platform handling. #801
Fix current platform handling. #801
Conversation
b59ade8
to
1629be8
Compare
Three aspects of current platform handling are fixed: 1. Ensure that `Platform.supported_tags` returns the full range of tags when the platform is current. This uses the special no-arg form of `pep425tags.get_supported` which consults the local interpreter to return the broadest possible set of tags. Also ensure that we always pass all compatible versions when the platform is not current to generate the broadest possible set of tags for the foreign platform. 2. Ensure that the resolver interprets 'current' to mean any local interpreter instead of just the current runtime interpreter. This is faithful to prior behavior where a PEX built for the 'current' platform would always work on the current machine. 3. Fix the PEX cli when run with a fully foreign set of `--platform`s. Previously the attempt to warn the user would error on an invalid log call that was missing a `V` argument. Tests of all of the above are added and platform parsing is pushed up to the CLI and resolver API layers for cleaner code under those layers and earlier failures for invalid platform specifiers.
1629be8
to
a97468d
Compare
N.B.: These issues were discovered trying to upgrade Pants to Pex 2.0.0. |
assert 1 == len(resolved_current) | ||
assert resolved_other != resolved_current | ||
assert resolved_current == resolve_current(interpreters=[current_python]) | ||
assert resolved_current == resolve_current(interpreters=[current_python, current_python]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand this line. When would you ever have two instances of the same interpreter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You wouldn't, but primarily this is test of de-duping and at the unit level, interpreters are handed in as a list, so an API user could hand in dups. More towards reality, given an interpreter constraint (that whole concept has been broken from the get-go really), you might collect a python 2.7.15 - say from pyenv, and a 2.7.17, say from the system. Since wheels / platform specifiers resolve only down to major/minor, these two different interpreters would produce the same wheels in which case we'd want to dedup.
# Here we have 2 local interpreters satisfying current but with different platforms and thus | ||
# different dists for 2 total dists. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the explanation!
@pytest.mark.skipif(PY_VER < (3, 5) or IS_PYPY, | ||
reason="The p537 distribution only builds for CPython 3.5+") | ||
def test_resolve_current_and_foreign_platforms(p537_resolve_cache): | ||
foreign_platform = 'macosx-10.13-x86_64-cp-37-m' if IS_LINUX else 'manylinux1_x86_64-cp-37-m' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Check on my understanding: the cp-37-m
piece is irrelevant here, even if running the test with a CP37 interpreter, correct? The reason for that is that the OS difference is enough for them to be different.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's relevant in that we need the test to work and cp-37-m is one of the pre-built wheels available. We need to have pre-built wheels available since wheel building is turned off & impossible when platforms are foreign: https://pypi.org/project/p537/#files
assert_tags( | ||
'linux-x86_64-cp-37-m', | ||
[ | ||
('cp37', 'cp37m', 'linux_x86_64'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should cp38
be added now that it's officially released?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps, but then the platform would need to change. The algorithm / correct answer is a countdown from 3.minor to 3.2 for abi3 wheels. Counting up to some arbitrary future minor ceiling is not a thing.
I'll defer 3.8 support to another PR, there is more that needs to be done in CI and tox.
def test_build_pex(): | ||
with temporary_dir() as sandbox: | ||
pex_path = os.path.join(sandbox, 'pex') | ||
results = run_pex_command(['ansicolors==1.1.8', '--output-file', pex_path]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh...all this time I thought 1.0.2
was the latest. Going to see if this newer version (still 2 years old) fixes the regex DeprecationWarning Pants CI is filled with.
Not a valid platform specifier: {} | ||
|
||
Platform strings must be in one of two forms: | ||
1. Canonical: <platform>-<python impl abbr>-<python version>-<abi> | ||
2. Abbreviated: <platform>-<python impl abbr>-<python version>-<abbr abi> | ||
|
||
Given a canonical platform string for CPython 3.7.5 running on 64 bit linux of: | ||
linux-x86_64-cp-37-cp37m | ||
|
||
Where the fields above are: | ||
+ <platform>: linux-x86_64 | ||
+ <python impl abbr>: cp | ||
+ <python version>: 37 | ||
+ <abi>: cp37m | ||
|
||
The abbreviated platform string is: | ||
linux-x86_64-cp-37-m | ||
|
||
These fields stem from wheel name conventions as outlined in | ||
https://www.python.org/dev/peps/pep-0427#file-name-convention and influenced by | ||
https://www.python.org/dev/peps/pep-0425. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fantastic explanation. Thank you.
Three aspects of current platform handling are fixed:
Ensure that
Platform.supported_tags
returns the full range of tagswhen the platform is current. This uses the special no-arg form of
pep425tags.get_supported
which consults the local interpreter toreturn the broadest possible set of tags. Also ensure that we always
pass all compatible versions when the platform is not current to
generate the broadest possible set of tags for the foreign platform.
Ensure that the resolver interprets 'current' to mean any local
interpreter instead of just the current runtime interpreter. This is
faithful to prior behavior where a PEX built for the 'current' platform
would always work on the current machine.
Fix the PEX cli when run with a fully foreign set of
--platform
s.Previously the attempt to warn the user would error on an invalid log
call that was missing a
V
argument.Tests of all of the above are added and platform parsing is pushed up to
the CLI and resolver API layers for cleaner code under those layers and
earlier failures for invalid platform specifiers.