-
Notifications
You must be signed in to change notification settings - Fork 541
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
[bzlmod] Silence Ignoring toolchain
warning for duplicate toolchains with the same configuration
#1818
Comments
Going through old issues and it looks like we have two options:
I am curious if the second option would be feasible here. |
I don't think the second is possible since if you didn't register one in the root modules your dependencies would have to exist. another less fun option would just be to allow users to disable this warning to avoid the noise if they are ok with the duplication |
I'd like to highlight this part of the original report, because that's true for the case I'm seeing as well:
This would also basically let folks that have two dependencies that do this in a way that collide and cause the warning avoid it by taking over managing the python toolchain registration in their root module. In a way, it makes that the option for users to disable the warning. |
This improve the toolchain's performance by about 10%. It will also allow us to leverage TCMalloc's extensions to do heap profiling and get other information about how efficiently we're using the heap. Note that currently this causes all of our builds to produce a warning due to an issue with `rules_python` and multiple modules registering python toolchains: bazelbuild/rules_python#1818
This improve the toolchain's performance by about 10%. It will also allow us to leverage TCMalloc's extensions to do heap profiling and get other information about how efficiently we're using the heap. Note that currently this causes all of our builds to produce a warning due to an issue with `rules_python` and multiple modules registering python toolchains: bazelbuild/rules_python#1818 This is also only enabled on Linux as there is no support for other OSes at the moment.
This improve the toolchain's performance by about 10%. It will also allow us to leverage TCMalloc's extensions to do heap profiling and get other information about how efficiently we're using the heap. Note that currently this causes all of our builds to produce a warning due to an issue with `rules_python` and multiple modules registering python toolchains: bazelbuild/rules_python#1818 This is also only enabled on Linux as there is no support for other OSes at the moment.
Recently we have added a That way we would have better experience out of the box. |
Warnings must be actionable: you must be able to do something to make the warning go away (either fix the root cause, or explicitly silence the warning). Otherwise, warning spam will simply accumulate, and you will miss new warnings. Currently, this warning isn't actionable---or at least, I as a user (and distributor of a non-root module) don't know what's the action I'm supposed to take to make it go away! Should I not register a
So it looks like in some situations, I ought to register the toolchain. (For example, rules_fuzzing appears to fall in this bucket.) How then do I avoid all my downstream users receiving this confusing warning? @aignas would downgrading this to INFO prevent it from being printed by default? That would be great in my opinion! |
as a quick workaround we've just patched out this warning to silence it |
Got a handy link to the patch out? Given silence here, interested in doing that too. |
diff --git a/python/private/bzlmod/python.bzl b/python/private/bzlmod/python.bzl
index 5862f00..3acd1ed 100644
--- a/python/private/bzlmod/python.bzl
+++ b/python/private/bzlmod/python.bzl
@@ -141,7 +141,7 @@ def _python_impl(module_ctx):
# module, they should not be warned for choosing the same
# version that rules_python provides as default.
first = global_toolchain_versions[toolchain_version]
- if mod.name != "rules_python" or not first.module.is_root:
+ if False:
_warn_duplicate_global_toolchain_version(
toolchain_version,
first = first, |
I wanted to submit a PR, but then I thought of a few reasons against it and TLDR: I think we should remove the warning and make it a env RULES_PYTHON_REPO_DEBUG_VERBOSITY=INFO bazel build //... Firstly, the root module can do whatever and the default version should ideally Secondly, the if python_name not in INTERPRETER_LABELS:
fail((
"Unable to find interpreter for pip hub '{hub_name}' for " +
"python_version={version}: Make sure a corresponding " +
'`python.toolchain(python_version="{version}")` call exists.' +
"Expected to find {python_name} among registered versions:\n {labels}"
).format(
hub_name = hub_name,
version = pip_attr.python_version,
python_name = python_name,
labels = " \n".join(INTERPRETER_LABELS),
)) This suggests me that the initial We do need to pass the interpreter label to the
So my thinking after writing all of the above is that we should fix the issue
P.S. Sorry for the long comment, I did not have time to write a shorter one. |
Before this PR we would warn when non-root modules register interpreter versions and the owners of root modules would have no way to silence the warning except for patching rules_python. This PR reduces the default verbosity of the warning to INFO to avoid spamming users by default. Fixes bazelbuild#1818.
Before this PR we would warn when non-root modules register interpreter versions and the owners of root modules would have no way to silence the warning except for patching rules_python. This PR reduces the default verbosity of the warning to INFO to avoid spamming users by default. Fixes #1818.
…-language#4133) This improve the toolchain's performance by about 10%. It will also allow us to leverage TCMalloc's extensions to do heap profiling and get other information about how efficiently we're using the heap. Note that currently this causes all of our builds to produce a warning due to an issue with `rules_python` and multiple modules registering python toolchains: bazelbuild/rules_python#1818 This is also only enabled on Linux as there is no support for other OSes at the moment.
With our project using bzlmod, rules_python, and grpc, with this setup in the MODULE.bazel:
When building you see this warning:
In this case it seems that grpc also registers a 3.11 toolchain when using it from bzlmod https://github.com/bazelbuild/bazel-central-registry/blob/5958c06f2695493509c6b8ad64c2774b2e25925c/modules/grpc/1.56.3.bcr.1/patches/python.patch#L22-L26
Which produces this through this code
rules_python/python/private/bzlmod/python.bzl
Line 144 in c5c03b2
In this case it doesn't seem like it's a problem, or that I can do anything about it? So I think it would be nice if it didn't produce a warning. Looking at the condition I am wondering if it is meant to be an
and
instead, sincefirst.module.is_root == True
in this case, but I don't understand the intent enough.🌍 Your Environment
Operating System: macOS
Output of
bazel version
: 7.1.1Rules_python version: HEAD
The text was updated successfully, but these errors were encountered: