pex.resolver.resolve does the wrong thing when given an interpreter and no platform
#511
Assignees
Labels
Comments
jsirois
changed the title
pex.resolver.resolve does the wrong thing when given an interpreter and no platformspex.resolver.resolve does the wrong thing when given an interpreter and no platform
jsirois
added a commit
to jsirois/pants
that referenced
this issue
Jun 6, 2018
This hacks around a few issues with the 1.4.x pex API. We concoct a minimal local `Platform` to pass to `resolve` where a local interpreter is passed to work around pex-tool/pex#511. We also now consolidate `PythonInterpreter` construction in production code to helper that ensures the interpreters we create are bare (isolated) except for the specific extras we require to work around pex-tool/pex#510. Upgrading pex to take advantage of the worked around issues noted above is tracked by pantsbuild#5922. Fixes pantsbuild#5906
jsirois
added a commit
to jsirois/pants
that referenced
this issue
Jun 6, 2018
This hacks around a few issues with the 1.4.x pex API. We concoct a minimal local `Platform` to pass to `resolve` where a local interpreter is passed to work around pex-tool/pex#511. We also now consolidate `PythonInterpreter` construction in production code to helper that ensures the interpreters we create are bare (isolated) except for the specific extras we require to work around pex-tool/pex#510. Upgrading pex to take advantage of the worked around issues noted above is tracked by pantsbuild#5922. Fixes pantsbuild#5906
jsirois
added a commit
to jsirois/pants
that referenced
this issue
Jun 6, 2018
This hacks around a few issues with the 1.4.x pex API. We concoct a minimal local `Platform` to pass to `resolve` where a local interpreter is passed to work around pex-tool/pex#511. We also now consolidate `PythonInterpreter` construction in production code to helper that ensures the interpreters we create are bare (isolated) except for the specific extras we require to work around pex-tool/pex#510. Upgrading pex to take advantage of the worked around issues noted above is tracked by pantsbuild#5922. Fixes pantsbuild#5906
jsirois
added a commit
to jsirois/pants
that referenced
this issue
Jun 7, 2018
This hacks around a few issues with the 1.4.x pex API. We concoct a minimal local `Platform` to pass to `resolve` where a local interpreter is passed to work around pex-tool/pex#511. We also now consolidate `PythonInterpreter` construction in production code to helper that ensures the interpreters we create are bare (isolated) except for the specific extras we require to work around pex-tool/pex#510. Upgrading pex to take advantage of the worked around issues noted above is tracked by pantsbuild#5922. Fixes pantsbuild#5906
jsirois
added a commit
to pantsbuild/pants
that referenced
this issue
Jun 7, 2018
This hacks around a few issues with the 1.4.x pex API. We concoct a minimal local `Platform` to pass to `resolve` where a local interpreter is passed to work around pex-tool/pex#511. We also now consolidate `PythonInterpreter` construction in production code to helper that ensures the interpreters we create are bare (isolated) except for the specific extras we require to work around pex-tool/pex#510. Upgrading pex to take advantage of the worked around issues noted above is tracked by #5922. Fixes #5906
jsirois
added a commit
to pantsbuild/pants
that referenced
this issue
Jul 13, 2018
Previously the platform passed for 'current' was partial, leading to ambiguous resolves. Further, partial platforms in user's BUILD files also would lead to ambiguous resolves. For example, a multi-platform `python_binary` with something like `platforms=['current', 'linux-x86_64', 'macosx_10.11_x86_64']`. Expand and and then fixup platforms as required by replacing `get_local_platform` with `expand_and_maybe_adjust_platform`. Also perform a few `build_local_python_distributions` fixes. + Fix an unused `interpreter` parameter - forward to `SetupPyRunner`. + Kill declaring `--universal` on behalf of the package author. There is not enough info to make the decision if the code being dist'd, if pure python, is 2/3 compatible. To compensate for the removal of `--universal`, give an example of how to declare your python_dist as `--universal` when you know it is as the BUILD `python_dist` target author. Finally two subsidary workarounds: + hack around PEX not forwarding custom interpreters to PEXEnvironment. + Avoid the troublesome Apple 2.7.10 python for now. Hacks are tracked by umbrella #5922, but for this PR they are: + pex-tool/pex#511 + pex-tool/pex#522 + pex-tool/pex#523
|
Turns out tests for #523 require this so folding it in there. |
Closed
jsirois
added a commit
to jsirois/pex
that referenced
this issue
Oct 2, 2018
Have this use pex intrinsics instead of pkg_resources which is known to report bad values on Apple-shipped inerpreters. Also fix resolver extended platform determination to support the test for the fix. Fixes pex-tool#511 Fixes pex-tool#523
jsirois
added a commit
to jsirois/pex
that referenced
this issue
Oct 3, 2018
Have this use pex intrinsics instead of pkg_resources which is known to report bad values on Apple-shipped inerpreters. Also fix resolver extended platform determination to support the test for the fix. Fixes pex-tool#511 Fixes pex-tool#523
jsirois
added a commit
that referenced
this issue
Oct 4, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Discovered working pantsbuild/pants#5910. If handed an interpreter different from the current one (
PythonInterpreter.get()) and noplatform, thePlatform.current()(ie: the platform of the current interpreter) is used bypex.resolver.resolve. The platform of the target interpreter passed in should be used in this case to avoid un-necessary systemic resolution failures.The text was updated successfully, but these errors were encountered: