Preserve absolute/relative paths in lockfiles

[EliteTK]

Summary

Attempt to track and preserve relative/absolute paths when read from files.

File URLs are treated as absolute. Synthetic VerbatimUrls shouldn't have a given, and are treated as relative.

This means that paths passed as absolute will be output as absolute, although they may get normalized. Paths passed as relative will be output as relative but they may be relative to a different location (so that they continue to work going forwards). Previously in various places we'd either make things absolute unconditionally or relative unconditionally.

Cases which should now be fixed:

• uv.lock - Path dependencies, indexes, and find-links were always converted to relative paths.
• pylock.toml export (from_resolution path) - Paths were always relativized. Now preserves the user's original format.
• pylock.toml export (from_lock path) - Relative paths from the lock file were being converted to absolute paths. Now uses the path exactly as stored in the lock file.

Also noteworthy is the bugfix for a windows misbehaviour. See the commit message for some more information.

Note: For now the uv add side of this has been split off as a breaking change.

Test Plan

Added missing tests, updated existing.

I believe all the changed tests are all now correct and were previously demonstrating buggy behaviour. Well, at least if you are on board with the idea that we should keep relative paths relative and absolute paths and / file URLs absolute.

Related Issues/PRs

• Closes Relative indexes are stored as absolute in the lockfile #15055
• Closes find-links or path = causes absolute wheel path to become relative path when creating lock file #16602
• Closes Allow cross-platform consistency in local file paths for pylock.toml exports #16514
• Closes Preserve relative paths in lockfiles for flat indices #15870

[konstin]

I consider changing the lockfiles fine - we shuffled those around before in regular releases - though the uv add change is user visible.

[konstin]

Should we pass the verbatim URL here instead so it can capture the logic about was_given_absolute?(probably needs to move to verbatim URL then)

I also noticed install_path and url: VerbatimUrl always come as a pair, do we want to bundle them?

[EliteTK]

I think if we bundled install_path and url together then it may make sense to have that type handle this.

An initial version of this PR had try_relative_to_if take the VerbatimUrl but I didn't feel like it made sense that way. Until we merge those, I feel like it strictly makes more sense to have them split up.

But I agree that all the code basically having the same combination of install_path and url.was_given_absolute() is an indication that there's an abstraction missing here.

I'll investigate the combination option.

[EliteTK]

I did investigate this, and the issue I am seeing is with RegistrySourceDist and RegistryBuiltWheel where there is no install_path but rather there is an IndexUrl which could be a file.

But the approach could work for PathBuiltDist, PathSourceDist, and DirectorySourceDist.

For the time being I've pushed a commit which reverts the uv add changes for this PR and created another PR which reverts the revert and is stacked. I've marked that other one breaking,

I've requested your re-review for this one just to double check I have actually reverted all the "breaking" changes.

[konstin]

Looks good!

[lheckemann]

I think this broke a use case I have: I used to specify some dependencies that live in the same repo and provide the same python package (and are included in mutually exclusive dependency groups) as

optional-dependencies.a = ["foo-a @ file:///${PROJECT_ROOT}/a"]
optional-dependencies.b = ["foo-b @ file:///${PROJECT_ROOT}/b"]

Up to now, this would generate lock files with relative paths that can be shared between systems where the repo lives in different places. This no longer works.

As a workaround, using

optional-dependencies.a = ["foo-a"]
optional-dependencies.b = ["foo-b"]

[tool.uv.sources]
foo-a = { path = "./a" }
foo-b = { path = "./b" }

seems to do the trick, but overall this does seem to be a bit more breaking than anticipated (producing lockfiles that aren't usable on other systems than the one that produced them, from pyproject configs that worked before)?

[konstin]

Can you describe in more detail in what case the tool.uv.sources solution doesn't work for you? Environment variables in pyproject.toml is kind of a hack, we strongly recommend tool.uv.sources over it.

[lheckemann]

It works fine in all the cases, but it breaks locking from older pyproject.tomls prior to the fix, i.e. requires changes to downstream consumers of uv. I think it makes a lot of sense to fix them, but is breaking enough that it shouldn't be in a point release.

[zanieb]

Thanks for the report! This should be fixed in 0.11.0