aspect-build / aspect-build/rules_py

py_binary and py_test analyzed rule kinds silently bypass rules_lint Python aspects

Open
#1,415 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.