fix(gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs by yushan26 · Pull Request #2822 · bazel-contrib/rules_python

yushan26 · 2025-04-24T22:21:24Z

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 · 2025-05-07T23:32:17Z

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 · 2025-05-08T04:59:30Z

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 · 2025-05-08T19:55:22Z

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.

linzhp · 2025-05-27T21:16:47Z

@dougthor42 can you also take a look at this PR?

One thing I am not sure is whether Gazelle can generate py_binary without generating py_library like @arrdem said.

dougthor42

One thing I am not sure is whether Gazelle can generate py_binary without generating py_library.

In general, yes this is possible. Given

# foo.pyif__name__=="__main__":
print("hey")

Then, assuming gazelle:python_generation_mode file, Gazelle will generate:

py_binary(
name="foo",
srcs= ["foo.py"],
)

However, package and project generation modes are different and TBH I'm less familiar with them.

dougthor42 · 2025-05-30T23:21:54Z

 multiple times.
 * (tools/wheelmaker.py) Extras are now preserved in Requires-Dist metadata when using requires_file
 to specify the requirements.
+* (gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs: https://github.com/bazel-contrib/rules_python/pull/2822


Wrap at ~80chars please

dougthor42 · 2025-05-30T23:44:17Z

+ }
+ pyLibrarySrcs := otherRule.AttrStrings("srcs")
+ for _, src := range pyLibrarySrcs {
+ if src == pyBinarySrcs[0] {


A py_binary can have multiple srcs so you don't want to check against only the 1st value.
What are the requirements for not indexing the binary?
Any binary source file is found in any py_library srcs?
All binary srcs are found in a single py_library? Eg binary.srcs is a subset of library.srcs.
All binary srcs are found in multiple py_library targets?

linzhp · 2025-05-31T04:43:58Z

Should we make Gazelle always generate py_library and stop indexing any py_binary? This is more consistent with other languages.

yushan26 · 2025-06-06T21:06:43Z

Should we make Gazelle always generate py_library and stop indexing any py_binary? This is more consistent with other languages.

Yea that's probably more consistent, although this may be unexpected behavior to the existing gazelle extension.

Update update

yushan26 · 2025-04-24T22:21:24Z

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 · 2025-05-07T23:32:17Z

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 · 2025-05-08T04:59:30Z

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 · 2025-05-08T19:55:22Z

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.

linzhp · 2025-05-27T21:16:47Z

@dougthor42 can you also take a look at this PR?

One thing I am not sure is whether Gazelle can generate py_binary without generating py_library like @arrdem said.

dougthor42

One thing I am not sure is whether Gazelle can generate py_binary without generating py_library.

In general, yes this is possible. Given

# foo.pyif__name__=="__main__":
print("hey")

Then, assuming gazelle:python_generation_mode file, Gazelle will generate:

py_binary(
name="foo",
srcs= ["foo.py"],
)

However, package and project generation modes are different and TBH I'm less familiar with them.

dougthor42 · 2025-05-30T23:21:54Z

 multiple times.
 * (tools/wheelmaker.py) Extras are now preserved in Requires-Dist metadata when using requires_file
 to specify the requirements.
+* (gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs: https://github.com/bazel-contrib/rules_python/pull/2822


Wrap at ~80chars please

dougthor42 · 2025-05-30T23:44:17Z

+ }
+ pyLibrarySrcs := otherRule.AttrStrings("srcs")
+ for _, src := range pyLibrarySrcs {
+ if src == pyBinarySrcs[0] {


A py_binary can have multiple srcs so you don't want to check against only the 1st value.
What are the requirements for not indexing the binary?
Any binary source file is found in any py_library srcs?
All binary srcs are found in a single py_library? Eg binary.srcs is a subset of library.srcs.
All binary srcs are found in multiple py_library targets?

linzhp · 2025-05-31T04:43:58Z

Should we make Gazelle always generate py_library and stop indexing any py_binary? This is more consistent with other languages.

yushan26 · 2025-06-06T21:06:43Z

Should we make Gazelle always generate py_library and stop indexing any py_binary? This is more consistent with other languages.

Yea that's probably more consistent, although this may be unexpected behavior to the existing gazelle extension.

Update update

yushan26 · 2025-04-24T22:21:24Z

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 · 2025-05-07T23:32:17Z

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 · 2025-05-08T04:59:30Z

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 · 2025-05-08T19:55:22Z

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.

linzhp · 2025-05-27T21:16:47Z

@dougthor42 can you also take a look at this PR?

One thing I am not sure is whether Gazelle can generate py_binary without generating py_library like @arrdem said.

dougthor42

One thing I am not sure is whether Gazelle can generate py_binary without generating py_library.

In general, yes this is possible. Given

# foo.pyif__name__=="__main__":
print("hey")

Then, assuming gazelle:python_generation_mode file, Gazelle will generate:

py_binary(
name="foo",
srcs= ["foo.py"],
)

However, package and project generation modes are different and TBH I'm less familiar with them.

dougthor42 · 2025-05-30T23:21:54Z

 multiple times.
 * (tools/wheelmaker.py) Extras are now preserved in Requires-Dist metadata when using requires_file
 to specify the requirements.
+* (gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs: https://github.com/bazel-contrib/rules_python/pull/2822


Wrap at ~80chars please

dougthor42 · 2025-05-30T23:44:17Z

+ }
+ pyLibrarySrcs := otherRule.AttrStrings("srcs")
+ for _, src := range pyLibrarySrcs {
+ if src == pyBinarySrcs[0] {


A py_binary can have multiple srcs so you don't want to check against only the 1st value.
What are the requirements for not indexing the binary?
Any binary source file is found in any py_library srcs?
All binary srcs are found in a single py_library? Eg binary.srcs is a subset of library.srcs.
All binary srcs are found in multiple py_library targets?

linzhp · 2025-05-31T04:43:58Z

Should we make Gazelle always generate py_library and stop indexing any py_binary? This is more consistent with other languages.

yushan26 · 2025-06-06T21:06:43Z

Should we make Gazelle always generate py_library and stop indexing any py_binary? This is more consistent with other languages.

Yea that's probably more consistent, although this may be unexpected behavior to the existing gazelle extension.

Update update

yushan26 · 2025-04-24T22:21:24Z

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 · 2025-05-07T23:32:17Z

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 · 2025-05-08T04:59:30Z

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 · 2025-05-08T19:55:22Z

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.

linzhp · 2025-05-27T21:16:47Z

@dougthor42 can you also take a look at this PR?

One thing I am not sure is whether Gazelle can generate py_binary without generating py_library like @arrdem said.

dougthor42

One thing I am not sure is whether Gazelle can generate py_binary without generating py_library.

In general, yes this is possible. Given

# foo.pyif__name__=="__main__":
print("hey")

Then, assuming gazelle:python_generation_mode file, Gazelle will generate:

py_binary(
name="foo",
srcs= ["foo.py"],
)

However, package and project generation modes are different and TBH I'm less familiar with them.

dougthor42 · 2025-05-30T23:21:54Z

 multiple times.
 * (tools/wheelmaker.py) Extras are now preserved in Requires-Dist metadata when using requires_file
 to specify the requirements.
+* (gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs: https://github.com/bazel-contrib/rules_python/pull/2822


Wrap at ~80chars please

dougthor42 · 2025-05-30T23:44:17Z

+ }
+ pyLibrarySrcs := otherRule.AttrStrings("srcs")
+ for _, src := range pyLibrarySrcs {
+ if src == pyBinarySrcs[0] {


A py_binary can have multiple srcs so you don't want to check against only the 1st value.
What are the requirements for not indexing the binary?
Any binary source file is found in any py_library srcs?
All binary srcs are found in a single py_library? Eg binary.srcs is a subset of library.srcs.
All binary srcs are found in multiple py_library targets?

linzhp · 2025-05-31T04:43:58Z

Should we make Gazelle always generate py_library and stop indexing any py_binary? This is more consistent with other languages.

yushan26 · 2025-06-06T21:06:43Z

Should we make Gazelle always generate py_library and stop indexing any py_binary? This is more consistent with other languages.

Yea that's probably more consistent, although this may be unexpected behavior to the existing gazelle extension.

Update update

yushan26 · 2025-04-24T22:21:24Z

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 · 2025-05-07T23:32:17Z

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 · 2025-05-08T04:59:30Z

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 · 2025-05-08T19:55:22Z

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.

linzhp · 2025-05-27T21:16:47Z

@dougthor42 can you also take a look at this PR?

One thing I am not sure is whether Gazelle can generate py_binary without generating py_library like @arrdem said.

dougthor42

One thing I am not sure is whether Gazelle can generate py_binary without generating py_library.

In general, yes this is possible. Given

# foo.pyif__name__=="__main__":
print("hey")

Then, assuming gazelle:python_generation_mode file, Gazelle will generate:

py_binary(
name="foo",
srcs= ["foo.py"],
)

However, package and project generation modes are different and TBH I'm less familiar with them.

dougthor42 · 2025-05-30T23:21:54Z

 multiple times.
 * (tools/wheelmaker.py) Extras are now preserved in Requires-Dist metadata when using requires_file
 to specify the requirements.
+* (gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs: https://github.com/bazel-contrib/rules_python/pull/2822


Wrap at ~80chars please

dougthor42 · 2025-05-30T23:44:17Z

+ }
+ pyLibrarySrcs := otherRule.AttrStrings("srcs")
+ for _, src := range pyLibrarySrcs {
+ if src == pyBinarySrcs[0] {


A py_binary can have multiple srcs so you don't want to check against only the 1st value.
What are the requirements for not indexing the binary?
Any binary source file is found in any py_library srcs?
All binary srcs are found in a single py_library? Eg binary.srcs is a subset of library.srcs.
All binary srcs are found in multiple py_library targets?

linzhp · 2025-05-31T04:43:58Z

Should we make Gazelle always generate py_library and stop indexing any py_binary? This is more consistent with other languages.

yushan26 · 2025-06-06T21:06:43Z

Should we make Gazelle always generate py_library and stop indexing any py_binary? This is more consistent with other languages.

Yea that's probably more consistent, although this may be unexpected behavior to the existing gazelle extension.

Update update

yushan26 · 2025-04-24T22:21:24Z

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 · 2025-05-07T23:32:17Z

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 · 2025-05-08T04:59:30Z

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 · 2025-05-08T19:55:22Z

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.

linzhp · 2025-05-27T21:16:47Z

@dougthor42 can you also take a look at this PR?

One thing I am not sure is whether Gazelle can generate py_binary without generating py_library like @arrdem said.

dougthor42

One thing I am not sure is whether Gazelle can generate py_binary without generating py_library.

In general, yes this is possible. Given

# foo.pyif__name__=="__main__":
print("hey")

Then, assuming gazelle:python_generation_mode file, Gazelle will generate:

py_binary(
name="foo",
srcs= ["foo.py"],
)

However, package and project generation modes are different and TBH I'm less familiar with them.

dougthor42 · 2025-05-30T23:21:54Z

 multiple times.
 * (tools/wheelmaker.py) Extras are now preserved in Requires-Dist metadata when using requires_file
 to specify the requirements.
+* (gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs: https://github.com/bazel-contrib/rules_python/pull/2822


Wrap at ~80chars please

dougthor42 · 2025-05-30T23:44:17Z

+ }
+ pyLibrarySrcs := otherRule.AttrStrings("srcs")
+ for _, src := range pyLibrarySrcs {
+ if src == pyBinarySrcs[0] {


A py_binary can have multiple srcs so you don't want to check against only the 1st value.
What are the requirements for not indexing the binary?
Any binary source file is found in any py_library srcs?
All binary srcs are found in a single py_library? Eg binary.srcs is a subset of library.srcs.
All binary srcs are found in multiple py_library targets?

linzhp · 2025-05-31T04:43:58Z

Should we make Gazelle always generate py_library and stop indexing any py_binary? This is more consistent with other languages.

yushan26 · 2025-06-06T21:06:43Z

Should we make Gazelle always generate py_library and stop indexing any py_binary? This is more consistent with other languages.

Yea that's probably more consistent, although this may be unexpected behavior to the existing gazelle extension.

Update update

yushan26 · 2025-04-24T22:21:24Z

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 · 2025-05-07T23:32:17Z

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 · 2025-05-08T04:59:30Z

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 · 2025-05-08T19:55:22Z

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.

linzhp · 2025-05-27T21:16:47Z

@dougthor42 can you also take a look at this PR?

One thing I am not sure is whether Gazelle can generate py_binary without generating py_library like @arrdem said.

dougthor42

One thing I am not sure is whether Gazelle can generate py_binary without generating py_library.

In general, yes this is possible. Given

# foo.pyif__name__=="__main__":
print("hey")

Then, assuming gazelle:python_generation_mode file, Gazelle will generate:

py_binary(
name="foo",
srcs= ["foo.py"],
)

However, package and project generation modes are different and TBH I'm less familiar with them.

dougthor42 · 2025-05-30T23:21:54Z

 multiple times.
 * (tools/wheelmaker.py) Extras are now preserved in Requires-Dist metadata when using requires_file
 to specify the requirements.
+* (gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs: https://github.com/bazel-contrib/rules_python/pull/2822


Wrap at ~80chars please

dougthor42 · 2025-05-30T23:44:17Z

+ }
+ pyLibrarySrcs := otherRule.AttrStrings("srcs")
+ for _, src := range pyLibrarySrcs {
+ if src == pyBinarySrcs[0] {


A py_binary can have multiple srcs so you don't want to check against only the 1st value.
What are the requirements for not indexing the binary?
Any binary source file is found in any py_library srcs?
All binary srcs are found in a single py_library? Eg binary.srcs is a subset of library.srcs.
All binary srcs are found in multiple py_library targets?

linzhp · 2025-05-31T04:43:58Z

Should we make Gazelle always generate py_library and stop indexing any py_binary? This is more consistent with other languages.

yushan26 · 2025-06-06T21:06:43Z

Should we make Gazelle always generate py_library and stop indexing any py_binary? This is more consistent with other languages.

Yea that's probably more consistent, although this may be unexpected behavior to the existing gazelle extension.

Update update

yushan26 · 2025-04-24T22:21:24Z

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 · 2025-05-07T23:32:17Z

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 · 2025-05-08T04:59:30Z

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 · 2025-05-08T19:55:22Z

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.

linzhp · 2025-05-27T21:16:47Z

@dougthor42 can you also take a look at this PR?

One thing I am not sure is whether Gazelle can generate py_binary without generating py_library like @arrdem said.

dougthor42

One thing I am not sure is whether Gazelle can generate py_binary without generating py_library.

In general, yes this is possible. Given

# foo.pyif__name__=="__main__":
print("hey")

Then, assuming gazelle:python_generation_mode file, Gazelle will generate:

py_binary(
name="foo",
srcs= ["foo.py"],
)

However, package and project generation modes are different and TBH I'm less familiar with them.

dougthor42 · 2025-05-30T23:21:54Z

 multiple times.
 * (tools/wheelmaker.py) Extras are now preserved in Requires-Dist metadata when using requires_file
 to specify the requirements.
+* (gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs: https://github.com/bazel-contrib/rules_python/pull/2822


Wrap at ~80chars please

dougthor42 · 2025-05-30T23:44:17Z

+ }
+ pyLibrarySrcs := otherRule.AttrStrings("srcs")
+ for _, src := range pyLibrarySrcs {
+ if src == pyBinarySrcs[0] {


A py_binary can have multiple srcs so you don't want to check against only the 1st value.
What are the requirements for not indexing the binary?
Any binary source file is found in any py_library srcs?
All binary srcs are found in a single py_library? Eg binary.srcs is a subset of library.srcs.
All binary srcs are found in multiple py_library targets?

linzhp · 2025-05-31T04:43:58Z

Should we make Gazelle always generate py_library and stop indexing any py_binary? This is more consistent with other languages.

yushan26 · 2025-06-06T21:06:43Z

Should we make Gazelle always generate py_library and stop indexing any py_binary? This is more consistent with other languages.

Yea that's probably more consistent, although this may be unexpected behavior to the existing gazelle extension.

Update update

yushan26 requested review from aignas and dougthor42 as code owners April 24, 2025 22:21

yushan26 force-pushed the index-py-library branch from cbeaaf2 to d37082dCompare May 8, 2025 19:51

yushan26 changed the title ~~Skip indexing py_binary rules~~Skip indexing py_binary rules if a corresponding py_library rule contains the same srcsMay 8, 2025

yushan26 changed the title ~~Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs~~fix(gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcsMay 27, 2025

yushan26 force-pushed the index-py-library branch from d37082d to 75c143dCompare May 27, 2025 20:39

yushan26 requested a review from rickeylev as a code owner May 27, 2025 20:39

dougthor42 reviewed May 30, 2025
View reviewed changes

This was referenced Jun 12, 2025
feat!: always generating py_library #2982
Draft
do not index py_binary unless in file mode #2989
Open

yushan8 added 5 commits June 24, 2025 22:03

Skip indexing py_binary rules
480e327
Update update

Update
aaef244

Update
b1bd1e7

Update
443fd7c

Update
373a0d1

yushan26 force-pushed the index-py-library branch from 75c143d to 373a0d1Compare June 24, 2025 22:13

yushan26 closed this Jul 1, 2025

yushan26 requested review from aignas and dougthor42 as code owners April 24, 2025 22:21

yushan26 force-pushed the index-py-library branch from cbeaaf2 to d37082dCompare May 8, 2025 19:51

yushan26 changed the title ~~Skip indexing py_binary rules~~Skip indexing py_binary rules if a corresponding py_library rule contains the same srcsMay 8, 2025

yushan26 changed the title ~~Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs~~fix(gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcsMay 27, 2025

yushan26 force-pushed the index-py-library branch from d37082d to 75c143dCompare May 27, 2025 20:39

yushan26 requested a review from rickeylev as a code owner May 27, 2025 20:39

dougthor42 reviewed May 30, 2025
View reviewed changes

This was referenced Jun 12, 2025
feat!: always generating py_library #2982
Draft
do not index py_binary unless in file mode #2989
Open

yushan8 added 5 commits June 24, 2025 22:03

Skip indexing py_binary rules
480e327
Update update

Update
aaef244

Update
b1bd1e7

Update
443fd7c

Update
373a0d1

yushan26 force-pushed the index-py-library branch from 75c143d to 373a0d1Compare June 24, 2025 22:13

yushan26 closed this Jul 1, 2025

yushan26 requested review from aignas and dougthor42 as code owners April 24, 2025 22:21

yushan26 force-pushed the index-py-library branch from cbeaaf2 to d37082dCompare May 8, 2025 19:51

yushan26 changed the title ~~Skip indexing py_binary rules~~Skip indexing py_binary rules if a corresponding py_library rule contains the same srcsMay 8, 2025

yushan26 changed the title ~~Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs~~fix(gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcsMay 27, 2025

yushan26 force-pushed the index-py-library branch from d37082d to 75c143dCompare May 27, 2025 20:39

yushan26 requested a review from rickeylev as a code owner May 27, 2025 20:39

dougthor42 reviewed May 30, 2025
View reviewed changes

This was referenced Jun 12, 2025
feat!: always generating py_library #2982
Draft
do not index py_binary unless in file mode #2989
Open

yushan8 added 5 commits June 24, 2025 22:03

Skip indexing py_binary rules
480e327
Update update

Update
aaef244

Update
b1bd1e7

Update
443fd7c

Update
373a0d1

yushan26 force-pushed the index-py-library branch from 75c143d to 373a0d1Compare June 24, 2025 22:13

yushan26 closed this Jul 1, 2025

yushan26 requested review from aignas and dougthor42 as code owners April 24, 2025 22:21

yushan26 force-pushed the index-py-library branch from cbeaaf2 to d37082dCompare May 8, 2025 19:51

yushan26 changed the title ~~Skip indexing py_binary rules~~Skip indexing py_binary rules if a corresponding py_library rule contains the same srcsMay 8, 2025

yushan26 changed the title ~~Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs~~fix(gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcsMay 27, 2025

yushan26 force-pushed the index-py-library branch from d37082d to 75c143dCompare May 27, 2025 20:39

yushan26 requested a review from rickeylev as a code owner May 27, 2025 20:39

dougthor42 reviewed May 30, 2025
View reviewed changes

This was referenced Jun 12, 2025
feat!: always generating py_library #2982
Draft
do not index py_binary unless in file mode #2989
Open

yushan8 added 5 commits June 24, 2025 22:03

Skip indexing py_binary rules
480e327
Update update

Update
aaef244

Update
b1bd1e7

Update
443fd7c

Update
373a0d1

yushan26 force-pushed the index-py-library branch from 75c143d to 373a0d1Compare June 24, 2025 22:13

yushan26 closed this Jul 1, 2025

yushan26 requested review from aignas and dougthor42 as code owners April 24, 2025 22:21

yushan26 force-pushed the index-py-library branch from cbeaaf2 to d37082dCompare May 8, 2025 19:51

yushan26 changed the title ~~Skip indexing py_binary rules~~Skip indexing py_binary rules if a corresponding py_library rule contains the same srcsMay 8, 2025

yushan26 changed the title ~~Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs~~fix(gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcsMay 27, 2025

yushan26 force-pushed the index-py-library branch from d37082d to 75c143dCompare May 27, 2025 20:39

yushan26 requested a review from rickeylev as a code owner May 27, 2025 20:39

dougthor42 reviewed May 30, 2025
View reviewed changes

This was referenced Jun 12, 2025
feat!: always generating py_library #2982
Draft
do not index py_binary unless in file mode #2989
Open

yushan8 added 5 commits June 24, 2025 22:03

Skip indexing py_binary rules
480e327
Update update

Update
aaef244

Update
b1bd1e7

Update
443fd7c

Update
373a0d1

yushan26 force-pushed the index-py-library branch from 75c143d to 373a0d1Compare June 24, 2025 22:13

yushan26 closed this Jul 1, 2025

yushan26 requested review from aignas and dougthor42 as code owners April 24, 2025 22:21

yushan26 force-pushed the index-py-library branch from cbeaaf2 to d37082dCompare May 8, 2025 19:51

yushan26 changed the title ~~Skip indexing py_binary rules~~Skip indexing py_binary rules if a corresponding py_library rule contains the same srcsMay 8, 2025

yushan26 changed the title ~~Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs~~fix(gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcsMay 27, 2025

yushan26 force-pushed the index-py-library branch from d37082d to 75c143dCompare May 27, 2025 20:39

yushan26 requested a review from rickeylev as a code owner May 27, 2025 20:39

dougthor42 reviewed May 30, 2025
View reviewed changes

This was referenced Jun 12, 2025
feat!: always generating py_library #2982
Draft
do not index py_binary unless in file mode #2989
Open

yushan8 added 5 commits June 24, 2025 22:03

Skip indexing py_binary rules
480e327
Update update

Update
aaef244

Update
b1bd1e7

Update
443fd7c

Update
373a0d1

yushan26 force-pushed the index-py-library branch from 75c143d to 373a0d1Compare June 24, 2025 22:13

yushan26 closed this Jul 1, 2025

yushan26 requested review from aignas and dougthor42 as code owners April 24, 2025 22:21

yushan26 force-pushed the index-py-library branch from cbeaaf2 to d37082dCompare May 8, 2025 19:51

yushan26 changed the title ~~Skip indexing py_binary rules~~Skip indexing py_binary rules if a corresponding py_library rule contains the same srcsMay 8, 2025

yushan26 changed the title ~~Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs~~fix(gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcsMay 27, 2025

yushan26 force-pushed the index-py-library branch from d37082d to 75c143dCompare May 27, 2025 20:39

yushan26 requested a review from rickeylev as a code owner May 27, 2025 20:39

dougthor42 reviewed May 30, 2025
View reviewed changes

This was referenced Jun 12, 2025
feat!: always generating py_library #2982
Draft
do not index py_binary unless in file mode #2989
Open

yushan8 added 5 commits June 24, 2025 22:03

Skip indexing py_binary rules
480e327
Update update

Update
aaef244

Update
b1bd1e7

Update
443fd7c

Update
373a0d1

yushan26 force-pushed the index-py-library branch from 75c143d to 373a0d1Compare June 24, 2025 22:13

yushan26 closed this Jul 1, 2025

yushan26 requested review from aignas and dougthor42 as code owners April 24, 2025 22:21

yushan26 force-pushed the index-py-library branch from cbeaaf2 to d37082dCompare May 8, 2025 19:51

yushan26 changed the title ~~Skip indexing py_binary rules~~Skip indexing py_binary rules if a corresponding py_library rule contains the same srcsMay 8, 2025

yushan26 changed the title ~~Skip indexing py_binary rules if a corresponding py_library rule contains the same srcs~~fix(gazelle): Skip indexing py_binary rules if a corresponding py_library rule contains the same srcsMay 27, 2025

yushan26 force-pushed the index-py-library branch from d37082d to 75c143dCompare May 27, 2025 20:39

yushan26 requested a review from rickeylev as a code owner May 27, 2025 20:39

dougthor42 reviewed May 30, 2025
View reviewed changes

This was referenced Jun 12, 2025
feat!: always generating py_library #2982
Draft
do not index py_binary unless in file mode #2989
Open

yushan8 added 5 commits June 24, 2025 22:03

Skip indexing py_binary rules
480e327
Update update

Update
aaef244

Update
b1bd1e7

Update
443fd7c

Update
373a0d1

yushan26 force-pushed the index-py-library branch from 75c143d to 373a0d1Compare June 24, 2025 22:13

yushan26 closed this Jul 1, 2025

Uh oh!

Uh oh!

Conversation

yushan26 commented Apr 24, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arrdem commented May 7, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

linzhp commented May 8, 2025

Uh oh!

yushan26 commented May 8, 2025

Uh oh!

linzhp commented May 27, 2025

Uh oh!

dougthor42 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

linzhp commented May 31, 2025

Uh oh!

yushan26 commented Jun 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

yushan26 commented Apr 24, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arrdem commented May 7, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

linzhp commented May 8, 2025

Uh oh!

yushan26 commented May 8, 2025

Uh oh!

linzhp commented May 27, 2025

Uh oh!

dougthor42 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

linzhp commented May 31, 2025

Uh oh!

yushan26 commented Jun 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

yushan26 commented Apr 24, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arrdem commented May 7, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

linzhp commented May 8, 2025

Uh oh!

yushan26 commented May 8, 2025

yushan26 commented Apr 24, 2025•
edited
Loading

arrdem commented May 7, 2025•
edited
Loading

yushan26 commented Apr 24, 2025•
edited
Loading

arrdem commented May 7, 2025•
edited
Loading

yushan26 commented Apr 24, 2025•
edited
Loading

arrdem commented May 7, 2025•
edited
Loading

yushan26 commented Apr 24, 2025•
edited
Loading

arrdem commented May 7, 2025•
edited
Loading