Gazelle Python plugin always includes Gazelle Proto plugin

[lazytype]

🐞 bug report

Affected Rule

The issue is caused by : `//python:gazelle_binary`

Is this a regression?

Yes, the previous version in which this bug was not present was: 1.5.3

Description

#3057 added support to the Python Gazelle plugin to generate py_proto_library targets and introduced a dependency on the Proto Gazelle plugin.

Now running //python:gazelle_binary with Gazelle will always run @bazel_gazelle//language/proto, even though py_proto_library target generation is disabled by default.

https://github.com/bazel-contrib/rules_python/blame/fb9b098f7f9aee57ef997392eab36a8a8debc138/gazelle/python/BUILD.bazel#L94

🔬 Minimal Reproduction

Remove the proto_library target from https://github.com/bazel-contrib/rules_python/blob/1.6.0-rc0/gazelle/python/testdata/directive_python_generate_proto/test3_disabled_with_proto/BUILD.in#L5-L9

and verify that https://github.com/bazel-contrib/rules_python/blob/1.6.0-rc0/gazelle/python/testdata/directive_python_generate_proto/test3_disabled_with_proto/BUILD.out#L5-L9 still gets generated with a proto_library target.

🔥 Exception or Error

n/a

🌍 Your Environment

Operating System:

  
MacOS
  

Output of bazel version:

  
Bazelisk version: 1.27.0
Aspect CLI version: 2025.32.3+d99ce1d9d
(14:56:03) INFO: Invocation ID: 88e9da43-a7fd-4e21-85f4-f8a1c1b20aa6
Build label: 8.3.0
  

Rules_python version:

  
1.6.0-rc0
  

Anything else relevant?

[aignas]

Known workaround is to define your own gazelle_binary target in your repo instead of relying on the rules_python one. @lazytype, does this work for you as the work around?

cc @shaldengeki as the author

[aignas]

@dougthor42, to restore the previous behaviour, maybe we should keep the default gazelle binary without the proto lang? What is your take on this?

[dougthor42]

Agreed. I think that we should revert the changes to gazelle_binary and make it so that, if people want to generate py_proto_library, they need to create a custom multi-lang gazelle target.

This wasn't caught during my local testing because we already generate proto_library targets. Oops!

I'll send out a fix today.