-
-
Notifications
You must be signed in to change notification settings - Fork 677
Description
🚀 feature request
Relevant Rules
This applies to the toolchain registration extensions.
Description
We have a product with multiple parallel python ecosystems, and I'm trying to make them more separate mentally, for our sanity. We're using the idiom described in #3671 (comment) to declare a custom family of toolchains, like:
string_flag(
name = "python_toolchain_family",
build_setting_default = "prebuilt",
values = ["prebuilt", "custom"]) and then we attached the custom config_setting to our custom toolchains (via target_settings) like:
native.toolchain(
...
target_settings = [
"@rules_python//python/config_settings:is_python_3.9",
"//thirdparty:python_toolchain_family_custom",
],
toolchain = "//thirdparty/Python39:runtime_pair",
toolchain_type = "@rules_python//python:toolchain_type",
)So far so good. However, the problem is, when we request an illegal combination, like:
py_binary(
python_version = "3.11",
config_settings = {
"//:python_toolchain_family": "custom"
}
)(when we didn't register 3.11 as a custom), we then get the default-registered python 3.11 toolchain, instead of getting a toolchain election error.
Describe the solution you'd like
I'd really like a way to unconditionally attach the config to all of the other registered toolchains, too, like
python.override(toolchain_target_settings = ["//:python_toolchain_family_prebuilt"])So there's a clean separation between our various custom ones and the prebuilt ones. I know this is possible manually with python.single_version_platform_override, but in order for this to work I have to attach it to the entire transitive graph of toolchains.
Describe alternatives you've considered
I'm not super familiar with the rules_python internals, but it might also make sense to attach it to something like config.add_transition_setting. I'm sure there are also probably ways to do this that I haven't thought of :)