Gazelle: Delete stale py_library and py_test targets

[taowang487]

Summary

Fix the issue #3375
Right now the py_library and py_test targets with missing srcs wouldn't be cleaned up by Gazelle in file mode.

This can be reproduced by a unit test added in commit ad0e48c

Testing

In commit ad0e48c , without the fix, bazel test //python/... failed in the newly added tests. The stale py_library and py_test cannot be removed.

In latest HEAD d32fb7b, bazel test //python/... can pass

INFO: From Testing //python:python_test_remove_invalid_per_file:
==================== Test output for //python:python_test_remove_invalid_per_file:
--- FAIL: TestGazelleBinary (0.02s)
    --- FAIL: TestGazelleBinary/remove_invalid_per_file (0.08s)
        python_test.go:186: remove_invalid_per_file/BUILD diff (-want,+got):
              (
                """
                ... // 8 identical lines
                )
              
            +   py_library(
            +       name = "deleted_lib",
            +       srcs = ["deleted.py"],
            +       visibility = ["//:__subpackages__"],
            +   )
            + 
            +   py_test(
            +       name = "bar_test",
            +       srcs = ["bar_test.py"],
            +   )
            + 
                py_test(
            -       name = "bar_test",
            -       srcs = ["bar_test.py"],
            +       name = "deleted_test",
            +       srcs = ["deleted_test.py"],
                )
                """
              )

[gemini-code-assist]

Code Review

This pull request updates Gazelle's Python extension to support identifying and removing invalid py_library and py_test targets by checking their sources against all regular files on disk, whereas previously only py_binary targets were validated. Feedback on the changes points out a critical issue where __main__.py might be incorrectly flagged as an invalid source for py_binary targets, and provides a suggestion to ensure it is added to the validation map if present.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

If __main__.py is present in the package, it is the standard entry point for py_binary targets. However, since __main__.py is not added to validFilesMap (which only contains main modules detected in appendPyLibrary and generated files), any existing py_binary target (including custom ones) that uses __main__.py as a source will be incorrectly marked as invalid and deleted by Gazelle.

We should ensure __main__.py is added to validFilesMap if it exists in args.RegularFiles.

	// allFilesMap extends validFilesMap with all regular files on disk.
	// py_binary uses validFilesMap (main modules + generated files), while py_library
	// and py_test use allFilesMap since any file is a valid src for them.
	allFilesMap := make(map[string]struct{}, len(validFilesMap)+len(args.RegularFiles))
	for file := range validFilesMap {
		allFilesMap[file] = struct{}{}
	}
	for _, file := range args.RegularFiles {
		allFilesMap[file] = struct{}{}
		if file == pyBinaryEntrypointFilename {
			validFilesMap[pyBinaryEntrypointFilename] = struct{}{}
		}
	}

[taowang487]

I don't think this comment is correct. Also added a test case for __main__.py in commit ad0e48c and the test can pass.

This target is not deleted by Gazelle

py_binary(
    name = "remove_invalid_per_file_bin",
    srcs = ["__main__.py"],
    main = "__main__.py",
    visibility = ["//:__subpackages__"],
)

[dougthor42]

Nice! Please also update CHANGELOG.md

[dougthor42]

Please add some test cases for aliased and mapped rules. For example, someone who has # gazelle:alias_kind my_py_test py_test or # gazelle:map_kind py_binary my_py_binary //bazel_wrappers:python.

It should be OK because you're using kindMatches, but I'd prefer the explicit test.