Repository navigation
feat(rules): add py_dist_info rule for importlib.metadata - #4357
pganssle-google wants to merge 2 commits into
Conversation
Libraries built directly from source with py_library (rather than installed from a wheel) do not have a .dist-info directory in runfiles, so runtime queries via importlib.metadata.version() or importlib.metadata.entry_points() fail unless the library is patched. This adds py_dist_info in //python:py_dist_info.bzl, which writes METADATA and entry_points.txt files and stages them via root_symlinks under <repo>/[target_path/]<package_name>.dist-info in runfiles so importlib.metadata can discover them on sys.path.
|
AI Disclosure: This PR was drafted with an AI coding assistant under @pganssle's close direction and review. @pganssle will review all feedback on this PR and either respond directly or review and approve any agent-assisted updates before they are posted. This is an automatically generated agent comment. -- I will not move this out of draft until after I have personally reviewed it. This is a human generated comment |
Previously, `py_wheel` constructed `.dist-info` metadata (`metadata.txt` and `entry_points.txt`) directly inside `_py_wheel_impl`, duplicating the metadata generation logic needed by `py_dist_info`. This expands `py_dist_info` to accept the full set of `.dist-info` metadata attributes (`distribution`, `version`, `author`, `classifiers`, `description_file`, `entry_points`, `extra_distinfo_files`, `extra_requires`, `requires`, `stamp`, etc.) and return a `PyDistInfo` provider alongside its runfiles `.dist-info` directory. `py_wheel` now accepts a `dist_info` attribute (defaulting to an implicit `<name>.dist_info` target generated by the `py_wheel` macro when metadata attributes are passed directly to `py_wheel`), and fails during analysis if an explicit `dist_info` target is combined with direct `.dist-info` attributes on `py_wheel`.
|
I like this idea in general. py_wheel has a lot of attributes that basically all boil down to creating the dist-info files, so moving that into a separate rule and target specifically for that sounds appealing. I also like the idea of letting a non-wheel library target being able to provide dist-info. Today, this is sort-of done in a sense already: when a wheel is extracted, a py_library contains both the package and the dist-info files, e.g. But this is hard to model in first-party py_library usage, where the "foo.py" isn't nested underneath other directories to allow foo.dist-info to also be put into the same py_library target. |
Libraries built from source with
py_library(rather than installedfrom a wheel) do not have a
.dist-infodirectory in runfiles, soruntime queries via
importlib.metadata.version()orimportlib.metadata.entry_points()fail unless the library is patched.Additionally, targets that also build a
py_wheelpreviously had no wayto share
.dist-infometadata definitions between runfiles and wheelpackaging.
This adds
py_dist_infoandPyDistInfoin//python:py_dist_info.bzlto generate
.dist-infometadata (METADATA,entry_points.txt, andextra_distinfo_files) staged viaroot_symlinksunder<repo>/[target_path/]<distribution>.dist-infoin runfiles.py_wheelnow delegates
.dist-infometadata generation topy_dist_infovia anew
dist_infoattribute (defaulting to an implicit<name>.dist_infotarget when metadata attributes are passed directly to
py_wheel).