[martvald]

Description:
With resolver = "uv", local find_links (file://%(buildroot)s/wheels) puts absolute checkout paths in the lockfile, so it only works where generated and misses cache elsewhere. path_mappings isn't supported for uv.

Issue is reproduced in martvald/pants-example-python:

• commit 1: local wheel with pex
• commit 2: uv with absolute path in lockfile

Three things leak the checkout path or machine state, one fix per commit:

1. Absolute find-links paths in uv.lock. uv writes find-links paths as given. Find-links under the buildroot are now passed to uv as relative paths, with their files in the sandbox. URLs and paths outside the buildroot are unchanged.

   # before
   source = { registry = "/home/me/repo/wheels" }
   wheels = [{ path = "/home/me/repo/wheels/my_wheel-0.1.0-py3-none-any.whl" }]
   # after
   source = { registry = "wheels" }
   wheels = [{ path = "my_wheel-0.1.0-py3-none-any.whl" }]

2. uv_cache.json baked into PEXes. For local wheels, uv writes <dist>.dist-info/uv_cache.json with the file's mtime:

   {"timestamp":{"secs_since_epoch":1792100808,"nanos_since_epoch":679638970},"commit":null,...}

   Pex copies it into the PEX, so the same PEX differed between CI and dev. Nothing else did. We now delete it after uv sync. Pex could arguably skip it, like INSTALLER.

3. Resolver args on PEXes with no requirements. pytest_runner.pex and local_dists.pex resolve nothing but still got --find-links=file:///<checkout>/.... They now return early, like the resolve-subsetting branch.

On our repo it solved all of our 89 tests missing cache with uv, all tests using repo hosted .whl files.

goal	Pex, 2.33.0	uv, 2.33.0	pex, this PR	uv, this PR
lint	190/216	187/217	197/216	212/217
test	246/246	157/246	246/246	246/246
package	773/786	774/787	774/786	778/787

LLM notice:

This PR was written primarily by Claude Code. I directed the testing and reviewed the result.

[jsirois]

@martvald a head's up would have been nice. I'm fixing this in Pex and pex.rc presently and should have releases out in the next few days. That said, see: https://docs.astral.sh/uv/reference/environment/#uv_no_installer_metadata - which works.

[martvald]

@martvald a head's up would have been nice. I'm fixing this in Pex and pex.rc presently and should have releases out in the next few days. That said, see: https://docs.astral.sh/uv/reference/environment/#uv_no_installer_metadata - which works.

Sorry for not reaching out first @jsirois . Great news, then I'll drop commit 2 since the proper fix is
coming in Pex. The other two are still needed on the Pants side: Pants passes find_links to uv
as absolute paths, and also passes them to PEXes with no requirements.

[jsirois]

@martvald I wouldn't rely on the Pex fix if I were you. Pex has to try to account for these files since it can't control the --venv-repository values its handed. That handling though could be enough today and not enough tomorrow (new metadata files introduced or new names for existing files). The verbage around https://docs.astral.sh/uv/reference/environment/#uv_no_installer_metadata and the PRs introducing it are all about stability / removing uv bookeeping from installs. That's exactly what you want and you can control it here since you create the venv in the 1st place and know its uv and know setting UV_NO_INSTALLER_METADATA=1 has the effect you want at a higher level.

[jsirois]

@martvald the Pex fix is out in https://github.com/pex-tool/pex/releases/tag/v2.104.1.

That said, I'll reiterate, don't rely on it. Set the env var instead.

[martvald]

@jsirois I really appreciate the effort you put into this. I have updated commit 2 to set UV_NO_INSTALLER_METADATA=1.

[martvald]

Ready for review. Addressed @jsirois feedback, now sets UV_NO_INSTALLER_METADATA=1. Could a maintainer approve the CI run?

[martvald]

@benjyw Thank you for the review. I have addressed all you comments in a new commit and rebased on origin/main.