Skip to content

fix(pypi): rewrite RECORD file entries for extracted .data contents - #4025

Draft
rickeylev wants to merge 12 commits into
bazel-contrib:mainfrom
rickeylev:verify_importlib_metadata_files
Draft

fix(pypi): rewrite RECORD file entries for extracted .data contents#4025
rickeylev wants to merge 12 commits into
bazel-contrib:mainfrom
rickeylev:verify_importlib_metadata_files

Conversation

@rickeylev

@rickeylev rickeylev commented Aug 9, 2026

Copy link
Copy Markdown
Collaborator

Extracting wheels with .data/ subdirectories moves files to their
target directories and deletes .data/, but left .dist-info/RECORD
referencing deleted .data/ paths. This causes tools like
importlib.metadata.files() to fail locating or reading files.

Per PEP 427 and PEP 376, rewrite .dist-info/RECORD entries during
wheel extraction to match installed locations relative to
site-packages.

  • Also adds Starlark unit tests for RECORD rewriting and expands
    importlib_metadata_test.

Work towards #3024

…and are readable

Expand importlib_metadata_test to assert that all files returned by
importlib.metadata.files() can be found on disk and read both as binary and
UTF-8 text. Update test fixture RECORD files to list installed paths.
…und and read

Assert that each file returned by importlib.metadata.files() exists and
can be read, reproducing the issue with unrewritten RECORD files.
Verify that the list of files returned by importlib.metadata.files()
matches the expected set of paths from the distribution's RECORD.
Sort expected_paths list alphabetically in source for improved readability.
When extracting wheels containing .data directories (purelib, platlib,
scripts, headers, data), the files are moved into their respective
target scheme directories and .data is deleted.

Rewrite .dist-info/RECORD entries so that archive member paths prefixed
with .data/ are updated to their installed paths relative to site-packages,
allowing tools like importlib.metadata.files() to locate and read them.
Also add Starlark unit tests for the RECORD rewriting logic.
@rickeylev rickeylev changed the title test(venv): [repro] importlib_metadata_test fails to find/read wheel files fix(pypi): rewrite RECORD file entries for extracted .data contents Aug 10, 2026
Unify extraction destinations and RECORD path rewrite prefixes into a
single _DATA_CATEGORIES mapping in whl_extract.bzl. Also add a news
entry fragment for the bug fix in bazel-contrib#4025.
…_test

On Windows, virtual environments have a 2-level directory depth
(Lib/site-packages) compared to POSIX 3-level depth
(lib/pythonX.Y/site-packages), so relative paths in RECORD starting with
.. cannot resolve via locate() on Windows. Skip locate() on Windows
for files outside site-packages.
Virtual environment directory structure depth differs between Windows
(`Lib/site-packages`) and POSIX (`lib/pythonX.Y/site-packages`).
Because the host platform during repo extraction cannot determine the
target platform, RECORD files must be generated per target platform.

Move extracted RECORD files to `rewrite-record/` and rewrite relative
paths for `.data` directories at build time via `gen_wheel_record`.
Update wheel_record_rewriter_test.sh to run .ps1 scripts via powershell.exe
when executing under Windows MSYS2 bash.

Update importlib_metadata_test.py to assert data_prefix ('../../') for
files originating in .data/data/bin/ and .data/data/include/ on Windows.
Convert input/output paths using cygpath -w when running powershell in
wheel_record_rewriter_test.sh and ignore CRLF differences in diff.

Handle .bat extension on Windows venv bin scripts when validating
located files in importlib_metadata_test.py.
@aignas

aignas commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

A few open questions:

  • Should we actually do this path manipulation where we extract it differently from the wheel layout? We are doing this because this was the layout before when we used to extract with installer.
  • Should we rename the RECORD file to something else, like RECORD.orig? We can generate a RECORD file from just the globs in a build action and that would mean it is always deterministic.

@rickeylev

Copy link
Copy Markdown
Collaborator Author

AFAIK, we're extracting the wheel the same as what other installers do, sans the later "install" part where it shows up into a binary's venv.

e.g. given https://github.com/bazel-contrib/rules_python/blob/main/tests/repos/whl_with_data1/whl_with_data1-1.0.dist-info/RECORD

  • platlib/ and purelib/ goes into site-packages
  • scripts goes into scripts; venv later puts it into $venv/bin/
  • headers/ goes into headers; venv later puts it into $venv/headers/
  • data/ goes into data; venv later puts it into $venv/ directly (e.g. data/XXX/foo.h will show up as $venv/XXX/foo.h

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.

2 participants