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:
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:
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:
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.
Ai written, human reviewed.
Problem
aspect_rules_pypublic macros do not retain their public rule names as their analyzed Bazel rule kinds:py_library(...)->py_librarypy_binary(...)->py_venv_execpy_test(...)->py_venv_exec_testThis breaks interoperability with
aspect_rules_lintaspects that select targets through exactrule_kindscomparisons. For example, the Ruff, ty, and pydoclint aspects default to conventional kinds such aspy_binary,py_library, andpy_test. Since aspects inspect the analyzed rule kind rather than the macro name, binaries and tests created throughaspect_rules_pyare 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_pymacros:Configure a rules_lint Python aspect with its default rule kinds, then inspect actions:
bazel aquery --include_aspects 'mnemonic(".*Ruff.*", //path:all)'The
py_librarysource receives a Ruff action, while thepy_binaryandpy_testsources do not. Addingpy_venv_execandpy_venv_exec_testexplicitly to the aspectrule_kindsmakes those actions appear.The behavior occurs with
aspect_rules_py2.0.0-alpha.5 and remains in 2.0.0-alpha.6. Upgrading between those versions does not resolve it.Expected behavior
Public
py_binaryandpy_testtargets 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 asaspect_rules_lintcan 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:
This workaround depends on internal analyzed rule-kind names and must be repeated for each kind-filtering aspect.