🚀 feature request

Relevant Rules

The Gazelle plugin

Description

Currently, the Gazelle plugin appears to collect all library *.py files in each directory and then generate a single py_library target for all of them. However, in my company's codebase this behavior generates lots of dependency cycles, since we have lots of situations like the following:

Three files: a/foo.py, a/bar.py, b/baz.py:

• a/foo.py imports b/baz.py
• b/baz.py imports a/bar.py

If we generate separate py_library targets for foo.py and bar.py, then no cycles result. With the current Gazelle plugin behavior, however, we instead get a single py_library for both foo.py and bar.py, which creates a dependency cycle with the py_library generated for baz.py.

I could of course see someone arguing that the above import structure represents bad practice, and suggesting refactoring our codebase to avoid these kinds of "directory cycles". It seems like a matter of opinion to me, though, and Bazel certainly supports finer-grained dependency tracking.

Describe the solution you'd like

Have an option to generate a single py_library for each library Python file? Or perhaps the ideal solution would be to only resort to this behavior when it's needed to break cycles?

Describe alternatives you've considered

Not sure -- very interested in potential workarounds that avoid painful refactors of our entire Python import structure...