bazel-contrib / bazel-contrib/rules_python
Optionally (?) regenerate `import` attributes
- Lenguaje dominante
- Starlark
- Estrellas
- 688
- Forks
- 721
- Merge medio
- 15 h 7 min
- PR fusionados (30 d)
- 76
Descripción
# 🚀 feature request
### Relevant Rules
Gazelle
### Description
The `python_root` directive will tell Gazelle to include the `imports` attribute on generated targets. Eg:
```starlark
py_library(
...
imports = ["../../.."],
...
)
```
However, when the `BUILD.bazel` and python files are moved, these `imports` are not updated when Gazelle processes that directory again, even if there were changes to the python files/imports/whatnot.
### Describe the solution you'd like
Hmm... one of:
1. Opt-in directive that tells Gazelle that it's OK to regenerate `imports`.
2. CLI arg for regenerating imports `bazel run //:gazelle -- --regen-imports` so that it can be run as a one-off
3. Always regenerate?
### Describe alternatives you've considered
Right now I run:
```
bazel run //:buildozer 'remove imports' //...:*; bazel run //:gazelle
```
Which is fine I guess. We currently use `bazel run //:gazelle` in CI to check that Gazelle won't make any modifications (CI fails if the git tree is dirty after running that command).
The problem with the above command and running it in CI is that we have targets that are intentionally _not_ managed by Gazelle. Those get modified by the `buildozer` command and then not fixed when running Gazelle.
I could probably update the `buildozer` command to ignore those unmanaged targets, but it would be quite messy - the unmanaged targets are a clusterfrack. It would be chaining `bazel query` to get the "exclude" syntax and then passing a list of managed targets to `buildozer`. Something like:
```shell
MANAGED_TARGETS=$(bazel query '//... except //foo/bar:* except //baz:* except //abc:apple')
bazel run //:buildozer 'remove imports' ${MANAGED_TARGETS}
bazel run //:gazelle
```
And I'd have to update that `query` when a new non-managed target/package is added.
Guía de contribución
Línea de trabajo
Comienza con la directiva `python_root`, los ejemplos de `BUILD.bazel` y el flujo de trabajo `bazel run //:gazelle` descritos aquí. Compara los enfoques de regeneración propuestos y cómo interactúan con los targets no gestionados y la comprobación de árbol sucio de CI. Se considera terminado cuando el comportamiento elegido actualiza los `imports` obsoletos sin modificar los targets que Gazelle no gestiona.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- python
- Área
- build-system
- Tipo de issue
- Nueva funcionalidad
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Estado de actividad
- Estancado
- Claridad
- Necesita aclaración
- Aptitud para principiantes
- 30/100