Hello @rickeylev, @aignas, modules you maintain (rules_python, rules_python_gazelle_plugin) have been updated in this PR.
Please review the changes. You can view a diff against the previous version in the "Generate module diff" check.

@bazelbuild/bcr-maintainers presubmit has been changed; needs maintainer to approve and trigger CI

@rickeylev @meteorcloudy the problem described in #6220 seems to persist. I can help look into it a bit later today if you don't get to it before me.

Hrm. I thought the shell_commands part of the presubmit fixed that; In #6219 I managed to get presubmits happy.

idea: maybe shell_commands needs to write to gazelle/examples/bzlmod_build_file_generation instead of the PWD?

In #6219, the MODULE.bazel file had local_path_override for rules_python commented out:

# The following loads rules_python from the file system.
# For usual setups you should remove this local_path_override block.
## local_path_override(
##     module_name = "rules_python",
##     path = "../../../asdf",
## )

So basically --override_module=rules_python= doesn't override the local_path_override, but if you convert local_path_override to --override_module=rules_python=../../.. in the .bazelrc file, the one in presubmit.yml will be able to override it.

Ahhh 🤦 Is that doc'd?

I've opened bazel-contrib/rules_python#3382 to fix that.

Ahhh 🤦 Is that doc'd?

I'm now thinking if that is the desired behaviour, maybe --override_module should actually take priority over other overrides. @Wyverald @fmeum WDYT ?

I see, the code is here:

    ImmutableMap<String, ModuleOverride> overrides =
        ImmutableMap.<String, ModuleOverride>builder()
            .putAll(moduleOverrides)
            .putAll(commandOverrides)
            .buildKeepingLast();

commandOverrides does take priority, but not when it's --override_module=foo=.

Since #6241 (comment) is available as a workaround, I think I slightly prefer the current behavior. Being able to "unoverride" a regular override via the CLI feels a bit too magical.

Can we get this submitted by EOD Wednesday the 29th? So that we can update bazel_tools before the Bazel 9 cut on Thursday.

We've put out an rc2 that reverts some pip integration changes: #6330

This pr (rc1) could be force merged if you just want some addressable version to put into Bazel 9. I think the part of interest to bazel are the flags, right? Those haven't changed in any of the 1.7 RCs.

I managed to comment out the local_path_override with a shell command, but hit

(12:54:46) ERROR: The module extension defined at /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/050984699b05a57a241a6299436a1652/external/rules_python~/python/private/python.bzl:857:26 does not have a tag class named defaults, but its use is attempted at /var/lib/buildkite-agent/builds/bk-docker-mgdv/bazel-org-repo-root/module_src/examples/bzlmod_build_file_generation/MODULE.bazel:51:16

afterwards, like #6330

I prefer to not force merge a broken version, so please fix this with a new rc.

FWIW, that error was present in prior release, just the local overrides were masking it. Its stemming from bazel_dep(name="rules_python", version="1.0.0"). Prior versions have version="0.0.0" (doesn't exist). In practice, users using the rules_python gazelle plugin are also using rules_python, so the version in the gazelle module usually doesn't matter.

In any case, I've created bazel-contrib/rules_python#3383 to fix (setting rules_python=1.4.0, which should suffice i think) and will start rc3 shortly.

This PR has been automatically marked as stale because it has not had any activity for 30 days. It will be closed in 14 days if no further activity occurs. Please comment on this PR to keep it open, or ask @bcr-maintainers to add the not stale label if it's still relevant.

This PR has been closed due to inactivity.