-
-
Notifications
You must be signed in to change notification settings - Fork 601
refactor: make python extension generate platform toolchains #2875
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
refactor: make python extension generate platform toolchains #2875
Conversation
096a3e2
to
e2c82f2
Compare
I want to cross check the generated BUILD files for toolchains to make sure they're the same semantically, so moving back to draft until I do so. From a cursory look, they look OK, but I changed the order of args, prefix length, etc, so the diff is pretty big. Gonna back those out to make it easier to compare them. |
e2c82f2
to
52f2b5d
Compare
Manually verified the registrations: they're OK. I tweaked the code a bit so it better matches the original ordering and naming. Ready for review. |
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.
Outside the scope of this PR, but I would love at some point to start registering the platform values in bazel-mod in the same way that they are done for uv.
During the refactor we forgot one more place where the `flag_values` on the platform information was used. They were no longer populated and broke. The solution is to use `selects.config_setting_group` to maintain behaviour and in order to smoke test I have added a target to verify that the aliases work. Fixup to #2875 Fixes #2993
During the refactor we forgot one more place where the `flag_values` on the platform information was used. They were no longer populated and broke. The solution is to use `selects.config_setting_group` to maintain behaviour and in order to smoke test I have added a target to verify that the aliases work. Related to #2875 Fixes #2993 Co-authored-by: Richard Levasseur <[email protected]>
…ntrib#3001) During the refactor we forgot one more place where the `flag_values` on the platform information was used. They were no longer populated and broke. The solution is to use `selects.config_setting_group` to maintain behaviour and in order to smoke test I have added a target to verify that the aliases work. Related to bazel-contrib#2875 Fixes bazel-contrib#2993 Co-authored-by: Richard Levasseur <[email protected]> (cherry picked from commit 107a878)
This makes the python bzlmod extension handle generating the platform-specific toolchain
entries ("python_3_10_{platform}"). This is to eventually allow adding additional
toolchains that aren't part of the PLATFORMS mapping in versions.bzl and have
their own custom constraints.
The main things this refactor does are:
to create (previously, it relied on
hub_repo
to generate the implementationnames).
it (the py_toolchain_suite.user_repository_repo arg) are separate. This allows
future work to mixin toolchains that point to arbitrary repos.
flag values. This allows more arbitrary target settings. For now, flag values
on the platform metadata is still looked for because it's known that users
patch python/versions.bzl.
Along the way:
are public visibility, but actually internal.
Work towards #2081