-
-
Notifications
You must be signed in to change notification settings - Fork 592
docs: document the is_python config settings #2336
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
docs: document the is_python config settings #2336
Conversation
If you need to match a version that isn't present, you can manually define | ||
a `config_setting` and have it match `python_version` or | ||
`python_version_major_minor`. |
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.
New versions can be added via python.single_override
, so it would be best to do that instead and then the config setting values will be updated. I think we should call out that for bzlmod
this is only needed if users are configuring/registering their own toolchains.
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.
I updated the text to mention both options. The main case I have in mind is for non-root modules: they may want to define their own to insulate themselves from what a root module might do. The other main case is for unreleased versions or, yes, customized toolchains.
Not sure if this is still needed given #2350. |
…o doc.is.python.config.settings
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.
Yeah, that PR will take care of most of the problem.
I think the doc is still necessary, though, since (1) the root module can cause targets to disappear, (2) we know people customize TOOL_VERSIONS, and (3) eventually we'll drop some of the very old python versions in our own versions file (or otherwise make them more of an opt-in type of thing).
If you need to match a version that isn't present, you can manually define | ||
a `config_setting` and have it match `python_version` or | ||
`python_version_major_minor`. |
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.
I updated the text to mention both options. The main case I have in mind is for non-root modules: they may want to define their own to insulate themselves from what a root module might do. The other main case is for unreleased versions or, yes, customized toolchains.
This documents the
//python/config_settings:is_python_*
config settings. It adds a disclaimerthat the available targets may vary depending on the root module settings, and tells users
how to match versions when one isn't available.