Gazelle not raising error when a target py_test exists in place of a py_binary
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 48/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- python
- Bereich
- build-system
Rechercherichtung
Beginnen Sie am Einstiegspunkt von rules_python_gazelle_plugin, der widersprüchliche generierte Targets behandelt, und verwenden Sie die bereitgestellte lib/demo-Reproduktion sowie den Befehl bazel run //:gazelle -- -strict -mode fix. Vergleichen Sie den Konflikt zwischen py_binary und py_test mit dem Fall py_library und py_test. Als erledigt gilt die Aufgabe, wenn der py_binary-Konflikt als Fehler gemeldet wird und der Befehl mit Status 1 beendet wird, konsistent mit dem anderen Konflikt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
🐞 bug report
Affected Rule
rules_python_gazelle_plugin functionality
Is this a regression?
Still needs assessment
Description
When gazelle runs over a BUILD file and finds a py_test target where it wants to make a py_binary target, the gazelle extension flags the conflict, but it does not elevate to an error. This is not the case for other target conflicts. For example, if a py_test exists where a py_library should, a full error is raised and the exit code respects this.
When this conflict happens, no other gazelle edits are recommended for the affected target. Recommendations to other targets proceed as normal.
🔬 Minimal Reproduction
Make a simple tree like
lib/demo/
- example_lib.py
- example_bin.py
- example_test.py
The contents of each are
example_bin.py
from lib.demo import example_lib
def main() -> None:
print("Lib call:", example_lib.some_helper())
if __name__ == "__main__":
main()
example_lib.py
def some_helper() -> int:
return 52
example_test.py
import unittest
from lib.demo import example_lib
def test_thing() -> None:
assert example_lib.some_helper() == 52
if __name__ == "__main__":
unittest.main()
Now make the BUILD file with the following contents
load("@rules_python//python:defs.bzl", "py_library", "py_test")
py_test(
name = "example_bin",
srcs = ["example_bin.py"],
)
py_library(
name = "example_lib",
srcs = ["example_lib.py"],
)
py_test(
name = "example_test",
srcs = ["example_test.py"],
)
Run bazel run //:gazelle -- -strict -mode diff and see the following output
$ bazel run //:gazelle -- -strict -mode fix
(21:34:13) INFO: Current date is 2026-02-16
(21:34:13) INFO: Analyzed target //:gazelle (0 packages loaded, 0 targets configured).
(21:34:13) INFO: Found 1 target...
Target //:gazelle up-to-date:
bazel-bin/gazelle-runner.bash
bazel-bin/gazelle
(21:34:13) INFO: Elapsed time: 0.129s, Critical Path: 0.05s
(21:34:13) INFO: 1 process: 4 action cache hit, 1 internal.
(21:34:13) INFO: Build completed successfully, 1 total action
gazelle: failed to generate target "//lib/demo:example_bin" of kind "py_binary": a target of kind "py_test" with the same name already exists
Now notice the difference in error when py_library is converted incorrectly to a py_test.
gazelle: failed to generate target "//lib/demo:example_bin" of kind "py_binary": a target of kind "py_test" with the same name already exists
gazelle: ERROR: failed to generate target "//lib/demo:example_lib" of kind "py_library": a target of kind "py_test" with the same name already exists. Use the '# gazelle:python_library_naming_convention' directive to change the naming convention.
The details are the same, but the latter scenario is reflected in the exit code with a value of 1.
🌍 Your Environment
Operating System:
debian linux
Output of bazel version:
8.4.2
Rules_python version:
1.8.3
- Vorherrschende Sprache
- Starlark
- Sterne
- 687
- Forks
- 726
- Ø Merge
- 1 T. 10 Std.
- Gemergte PRs (30 T.)
- 69
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus bazel-contrib/rules_python
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
bazel-contrib/rules_python#4251 · 1 Reaktion ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
bazel-contrib/rules_python#4201 · 3 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
bazel-contrib/rules_python#4164 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
go:embed stdlib_list.txt file in gazelle/python/std_modules.go is missingEvtl. vergeben @udaya2899 hat das vor 15 Tagen übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
bazel-contrib/rules_python#3821 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 20/100
bazel-contrib/rules_python#4250 ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in bazel-contrib/rules_python
Ähnliche Issues
-
Build failure: limoOffen0.kind: build failure
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 1 Tag
-
area:contributor-experience bug difficulty:easy good first issue Stellar Wave
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
Maintainer antworten meist innerhalb von 2 Tagen
-
Upgrade to Go 1.27.1Offenhelp wanted
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 66/100
-
Upgrade to Go 1.27.1Offenhelp wanted
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
meshery-extensions/meshery-mcp-server#63 · 1 Kommentar ·
-
Upgrade to Go 1.27.1Offenhelp wanted
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100