refactor: add a version label function for consistent labels #1328
Conversation
This file contains 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
aignas
force-pushed
the
refactor/version-label-func
branch
from
2db1440
to
c3d7224
Compare
chrislovecnm
approved these changes
Jul 23, 2023
This was referenced Jul 24, 2023
aignas
added a commit
to aignas/rules_python
that referenced
this pull request
Jul 24, 2023
Before this PR the `bzlmod` example would only work if the Python interpreter version is specified in the `X.Y` format. However, users may desire to use the full version (`X.Y.Z`) for reproducibility reasons and expect everything to continue to work. This fixes the versions used everywhere by leveraging functionality introduced in bazelbuild#1328 and fixes the `python_versions` to always contain `@python_versions//X.Y:defs.bzl` imports. NOTE, bazelbuild#1328 also fixed the case where the Python-version specific `pip` hub repos would be named `<hub_name>_XYZ` as opposed to the `<hub_name>_XY`, which is expected across the codebase. Breaking for `bzlmod` users who previously used `@python_versions//X.Y.Z:defs.bzl` in their BUILD.bazel files and/or depended on the `@pip_XYZ//:requirements.bzl`. This essentially limits the users of the `@python_versions` to a single `X.Y` toolchain version, whilst the full functionality should still be available by using the `python_version` parameter in the `py_binary` and `py_library` rules. Fixes bazelbuild#1339.
aignas
added a commit
to aignas/rules_python
that referenced
this pull request
Jul 29, 2023
Before this PR the `bzlmod` example would only work if the Python interpreter version is specified in the `X.Y` format. However, users may desire to use the full version (`X.Y.Z`) for reproducibility reasons and expect everything to continue to work. This fixes the versions used everywhere by leveraging functionality introduced in bazelbuild#1328 and fixes the `python_versions` to always contain `@python_versions//X.Y:defs.bzl` imports. NOTE, bazelbuild#1328 also fixed the case where the Python-version specific `pip` hub repos would be named `<hub_name>_XYZ` as opposed to the `<hub_name>_XY`, which is expected across the codebase. Breaking for `bzlmod` users who previously used `@python_versions//X.Y.Z:defs.bzl` in their BUILD.bazel files and/or depended on the `@pip_XYZ//:requirements.bzl`. This essentially limits the users of the `@python_versions` to a single `X.Y` toolchain version, whilst the full functionality should still be available by using the `python_version` parameter in the `py_binary` and `py_library` rules. Fixes bazelbuild#1339.
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.
Before this PR there would be at least a few places where we would be
converting a
X.Y.Zversion string to a shortenedX_YorXYstring segmentto be used in repository rule labels. This PR adds a small utility function
that helps making things consistent.
Work towards #1262, split from #1294.