Skip to content

Conversation

ElanHR
Copy link

@ElanHR ElanHR commented Jun 6, 2025

Passing tags to py_pytest_main allows them to be excluded from mypy type checking.

Current implementation of pytest-generated code does not adhere to strict type safety and gives the following mypy errors:

bazel-out/.../my_test.pytest_main.py:37: error: Argument 1 to "open" has incompatible type "str | None"; expected "int | str | bytes | PathLike[str] | PathLike[bytes]"  [arg-type]
bazel-out/.../my_test.pytest_main.py:78: error: Argument 1 to "int" has incompatible type "str | None"; expected "str | Buffer | SupportsInt | SupportsIndex | SupportsTrunc"  [arg-type]
bazel-out/.../my_test.pytest_main.py:84: error: Argument 1 to "Path" has incompatible type "str | None"; expected "str | PathLike[str]"  [arg-type]
bazel-out/.../my_test.pytest_main.py:109: error: Unsupported left operand type for + ("None")  [operator]
bazel-out/.../my_test.pytest_main.py:109: note: Left operand is of type "str | None"
bazel-out/.../my_test.pytest_main.py:114: error: Argument 1 to "open" has incompatible type "str | None"; expected "int | str | bytes | PathLike[str] | PathLike[bytes]"  [arg-type]

The current workaround to exclude these tests via tags however these are not currently passed to generated py_pytest_main.


Changes are visible to end-users: yes

  • Searched for relevant documentation and updated as needed: yes
  • Breaking change (forces users to change their own code or config): no
  • Suggested release notes appear below: yes

Enables py_test tags passing to generated py_pytest_main

Test plan

Build/Unit tests

bazel build //...
bazel test //...
  • Manual testing; please provide instructions so we can reproduce:

tools/aspects.bzl:

load("@pip_types//:types.bzl", "types")
load("@rules_mypy//mypy:mypy.bzl", "mypy")

mypy_aspect = mypy(
	mypy_ini = "@@//:mypy.ini",
	types = types,
	suppression_tags = ["no-mypy", "no-checks"],
)

...<path_to_my_test>/BUILD.bazel:

py_test (
  name = "my_test",
  srcs = ["my_test.py"],
  pytest_main = True,
  deps = [
     ...
  ],
  tags = ["no-mypy"],
)

No mypy errors are raised.

@CLAassistant
Copy link

CLAassistant commented Jun 6, 2025

CLA assistant check
All committers have signed the CLA.

Copy link

aspect-workflows bot commented Jun 6, 2025

Test

1 test target passed

Targets
//docs:update_2_test [k8-fastbuild]                 80ms

Total test execution time was 80ms. 38 tests (97.4%) were fully cached saving 1m 9s.

@arrdem
Copy link
Collaborator

arrdem commented Jun 6, 2025

Is this required with #577? In general I'm not convinced there's correct behavior for macros to pass tags down to the other rules/macros they invoke, so this feels like the wrong approach to me.

@arrdem arrdem self-requested a review June 6, 2025 18:58
@ElanHR
Copy link
Author

ElanHR commented Jun 24, 2025

Thanks for the pointer - #577 does indeed address this issue!

I was also able to replicate the behavior in this PR using --incompatible_allow_tags_propagation.

Per https://blog.aspect.build/bazelrc-flags :

common --incompatible_allow_tags_propagation: ensure that tags applied in your BUILD file, like tags = ["no-remote"] get propagated to actions created by the rule. Without this option, you rely on rules authors to manually check the tags you passed and apply relevant ones to the actions they create. See bazelbuild/bazel#7766

@ElanHR ElanHR closed this Jun 24, 2025
@arrdem
Copy link
Collaborator

arrdem commented Jun 25, 2025

Glad we were able to find you a solution! I think that tag propagation semantics are generally pretty fraught because does the same set of tags you apply to some intentional target really apply to the targets it may need as intermediaries....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants