{rules_python,rules_python_gazelle_plugin}@1.7.0-rc1

[bazel-contrib-bot]

Release: https://github.com/bazel-contrib/rules_python/releases/tag/1.7.0-rc1

Automated by Publish to BCR

[bazel-io]

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.

[rickeylev]

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

[Wyverald]

@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.

[rickeylev]

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?

[meteorcloudy]

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.

[rickeylev]

Ahhh 🤦 Is that doc'd?

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

[meteorcloudy]

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 ?

[meteorcloudy]

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=.

[fmeum]

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.

[Wyverald]

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

[rickeylev]

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.

Require module maintainers' approval for newly pushed changes.

[meteorcloudy]

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.

[rickeylev]

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.