Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs

[yushan26]

This PR ensures that py_binary rules are not indexed into Gazelle's IndexMap when there is a corresponding py_library rule with the same srcs. When both py_library and py_binary targets share the same file in their srcs, Gazelle previously indexed both under the same import path. This led to ambiguity and resolution errors, as Gazelle found multiple rules for the same language (py).

To resolve this, the PR updates Gazelle to skip indexing py_binary rules, allowing py_library to be the only import being indexed.

Testing
An integration test was added where both a py_library and a py_binary rule include the same script.py in their srcs. The test verifies that Gazelle correctly resolves the import to the py_library target.

[arrdem]

I don't think that just not indexing py_binary sources is a workable solution. A pattern we've seen before is that users will want to consider sources part of a py_binary and explicitly not want to manage what's perceived to be a duplicate py_library target, instead expecting other use sites to depend on that fileset via the py_binary target.

This has obvious downsides in that the entrypoint script gets materialized among other things, but it's an existing and working use-case.

I think the behavior in this case should simply be to prefer the library target in case both are an option, not ignoring binaries entirely.

[linzhp]

A pattern we've seen before is that users will want to consider sources part of a py_binary and explicitly not want to manage what's perceived to be a duplicate

Are you talking about the scenarios when py_binary is generated but not py_library?

[yushan26]

Gotcha, I updated the logic to skip indexing the py_binary rule only if there is a corresponding py_library rule that also has the samesrcs populated. Let me know if this makes sense.