aspect-build / aspect-build/rules_py
py_binary and py_test analyzed rule kinds silently bypass rules_lint Python aspects
- Dominant language
- Starlark
- Stars
- 145
- Forks
- 97
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 71
Description
Ai written, human reviewed.
## Problem
`aspect_rules_py` public macros do not retain their public rule names as their analyzed Bazel rule kinds:
- `py_library(...)` -> `py_library`
- `py_binary(...)` -> `py_venv_exec`
- `py_test(...)` -> `py_venv_exec_test`
This breaks interoperability with `aspect_rules_lint` aspects that select targets through exact `rule_kinds` comparisons. For example, the Ruff, ty, and pydoclint aspects default to conventional kinds such as `py_binary`, `py_library`, and `py_test`. Since aspects inspect the analyzed rule kind rather than the macro name, binaries and tests created through `aspect_rules_py` are silently skipped.
The failure mode is especially risky because lint succeeds with no diagnostic or indication that target sources were not visited.
## Reproduction
Create targets using the public `aspect_rules_py` macros:
```starlark
load("@aspect_rules_py//py:defs.bzl", "py_binary", "py_library", "py_test")
py_library(name = "lib", srcs = ["lib.py"])
py_binary(name = "bin", srcs = ["bin.py"])
py_test(name = "test", srcs = ["test.py"])
```
Configure a rules_lint Python aspect with its default rule kinds, then inspect actions:
```shell
bazel aquery --include_aspects 'mnemonic(".*Ruff.*", //path:all)'
```
The `py_library` source receives a Ruff action, while the `py_binary` and `py_test` sources do not. Adding `py_venv_exec` and `py_venv_exec_test` explicitly to the aspect `rule_kinds` makes those actions appear.
The behavior occurs with `aspect_rules_py` 2.0.0-alpha.5 and remains in 2.0.0-alpha.6. Upgrading between those versions does not resolve it.
## Expected behavior
Public `py_binary` and `py_test` targets should interoperate with tooling aspects that recognize the standard public rule kinds, or the nonstandard analyzed kinds should be exposed as a documented compatibility contract that downstream tools such as `aspect_rules_lint` can support reliably. Ideally, use of the public macros should not cause lint coverage to disappear silently.
## Current workaround
Repositories must override every affected Python lint aspect:
```starlark
PYTHON_RULE_KINDS = ["py_library", "py_venv_exec", "py_venv_exec_test"]
ruff = lint_ruff_aspect(rule_kinds = PYTHON_RULE_KINDS, ...)
ty = lint_ty_aspect(rule_kinds = PYTHON_RULE_KINDS, ...)
pydoclint = lint_pydoclint_aspect(rule_kinds = PYTHON_RULE_KINDS, ...)
```
This workaround depends on internal analyzed rule-kind names and must be repeated for each kind-filtering aspect.
Contributor guide
Research direction
Start with the public macros loaded from @aspect_rules_py//py:defs.bzl and reproduce the missing Ruff actions using the provided Bazel aquery command. Compare the analyzed kinds for py_library, py_binary, and py_test with the rule_kinds selected by the lint aspects. Done means binary and test sources are covered by standard aspect defaults, or the nonstandard kinds have a documented compatibility contract.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- build-system, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100