fix(pypi) backport python_full_version fix to Python#2833
Merged
aignas merged 2 commits intobazel-contrib:mainfrom Apr 28, 2025
Merged
fix(pypi) backport python_full_version fix to Python#2833aignas merged 2 commits intobazel-contrib:mainfrom
aignas merged 2 commits intobazel-contrib:mainfrom
Conversation
This has been fixed in the Starlark implementation in bazel-contrib#2793 and in this PR I am backporting the changes to handle the full python version target platform strings so that we can have the same behaviour for now. At the same time I have simplified and got rid of the specialization handling in the Python algorithm just like I did in the starlark, which simplifies the tests and makes the algorithm more correct. Work towards bazel-contrib#2830
rickeylev
approved these changes
Apr 27, 2025
aignas
commented
Apr 28, 2025
aignas
added a commit
that referenced
this pull request
Apr 29, 2025
Handling of `python_full_version` correctly has been fixed in the Starlark implementation in #2793 and in this PR I am backporting the changes to handle the full python version target platform strings so that we can have the same behaviour for now. At the same time I have simplified and got rid of the specialization handling in the Python algorithm just like I did in the starlark, which simplifies the tests and makes the algorithm more correct. Summary: * Handle `cp3x.y_os_arch` strings in the `platform.py` * Produce correct strings when the `micro_version` is unset. Note, that we use version `0` in evaluating but we use the default version in the config setting. This is to keep compatibility with the current behaviour when the target platform is not fully specified (which would be the case for WORKSPACE users). * Adjust the tests and the code to be more similar to the starlark impl. Work towards #2830 (cherry picked from commit 9e613d5)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Handling of
python_full_versioncorrectly has been fixed in the Starlarkimplementation in #2793 and in this PR I am backporting the changes to handle
the full python version target platform strings so that we can have the same
behaviour for now.
At the same time I have simplified and got rid of the specialization handling
in the Python algorithm just like I did in the starlark, which simplifies the
tests and makes the algorithm more correct.
Summary:
cp3x.y_os_archstrings in theplatform.pymicro_versionis unset. Note, that we use version0in evaluating but we use the default version in the config setting. This is to keep compatibility with the current behaviour when the target platform is not fully specified (which would be the case for WORKSPACE users).Work towards #2830