bazel-contrib / bazel-contrib/rules_python
Gazelle target generation (breaking) changed in 1.6.0
- Dominant language
- Starlark
- Stars
- 688
- Forks
- 721
- Avg merge
- 14h 49m
- Merged PRs (30d)
- 81
Description
# 🐞 bug report
### Affected Rule
`py_test`/`py_library` (and Gazelle, not a rule)
### Is this a regression?
I'd argue so 😓. https://github.com/bazel-contrib/rules_python/pull/2998 introduced the new behavior (released in 1.6.0).
(more details in description)
### Description
(Before I begin, please note I _like_ https://github.com/bazel-contrib/rules_python/pull/2998 as a change. I just don't like a seemingly breaking change without any warning or toggles or migration path).
I'm upgrading my work monorepo `rules_python` to the latest, version-by-version. `1.6.0` has apparently become a very hard stop on my journey, due to incompatible gazelle changes. At a high level this is because:
- After upgrade, `gazelle` is happy to add new targets, while leaving the old targets alone
- There's no way to emulate the old behavior. The closest is trying different `# gazelle:python_generation_mode`s to see what gives me a small (enough) diff
- There's no way to incrementally roll this out (e.g. the result is one mega-PR)
- Whereas the old way made it so you could cleverly solve import cycles (across multiple subdirs) the new way makes that challenging
- [conftest inclusion is a bit broken](https://github.com/bazel-contrib/rules_python/issues/3497)
## 🔬 Minimal Reproduction
(I'll try and work on a demo repo showing each of the bullet points above, bear with me)
## 🔥 Exception or Error
(N/A)
## 🌍 Your Environment
(N/A)
Contributor guide
Assessment
This issue has not been assessed yet.