py.typed missing from pypi-published bazel-runfiles wheel causes mypy to fail to import

[aaronsky]

🐞 bug report

Affected Rule

I'm filing this issue with regards to the bazel-runfiles package published to PyPI.

Is this a regression?

unknown

Description

I can see in the wheel that there is no py.typed marker file, even though this file is provided as data to the py_library here. This omission causes Mypy to fail to import the package's type hints, and produces an error when running Mypy without rules_mypy (such as in my IDE). My understanding of how Mypy works, based on the information here and the fact that bazel-runfiles is not a stubs package, is that this py.typed file is required in order for Mypy to work.

Is this working as designed?

🔬 Minimal Reproduction

Download the wheel from here and observe the absent py.typed file.

🔥 Exception or Error

ci/bazel/testing/unit/collect_test_results.py:8: error: Skipping analyzing "runfiles": module is installed, but missing library stubs or py.typed marker  [import-untyped]
ci/bazel/testing/unit/collect_test_results.py:8: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports

🌍 Your Environment

Operating System:

  
macOS 15.2
  

Output of bazel version:

  
Bazelisk version: 1.25.0
INFO: Invocation ID: 6cddecd0-8331-45bd-9d3b-1db39b6d2abb
Build label: 7.4.1
Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer
Build time: Mon Nov 11 21:27:36 2024 (1731360456)
Build timestamp: 1731360456
Build timestamp as int: 1731360456
  

Rules_python version:

  
1.0.0
  

Anything else relevant?

[rickeylev]

py_wheel is implemented very differently than I expected. Namely, it isn't transitive in nature. The files it packages are ctx.files.deps i.e. the default (direct) outputs of the targets in deps. So, given a py_library as input, it'll only include the .py files from that direct target. Hm, though, this makes some sense. We want to be fairly explicit in what goes into a package. We don't want to package external transitive dependencies, and it'd be easy to accidentally package higher order dependencies that aren't supposed to be part of the package itself.

Ah -- is the problem that we're passing py_library to py_wheel, not py_package?

Hm, though in the example for py_wheel, it has this:

# Package some specific py_library targets, without their dependencies
py_wheel(
    # Package data. We're building "example_minimal_library-0.0.1-py3-none-any.whl"
   ...
    deps = [
        "//examples/wheel/lib:module_with_data",
        ...
    ],
)

Where module_with_data is a py_library with data set. And there's a test for this? Hm.

In any case, an immediate fix is to add py.typed to the py_wheel for runfiles. Not sure if there's a regression with py_wheel or not (that code hasn't changed much in a long time)