iron out how to represent path dependencies in the universal lock file

[BurntSushi]

We want to support path dependencies in our lock file. But the data model for path dependencies in our lock file is, at the time of writing, not quite right. I believe what we ought to have for a path dependency is a single file URL to a directory, source distribution or wheel. But the data model currently allows for a source distribution and zero or more wheels, but specifically does not allow for a directory.

I think the current data model is mostly just a reaction to the types that we have after resolution. Namely, I think we have two related types. The first is for wheel path dependencies:

uv/crates/distribution-types/src/lib.rs

Lines 174 to 180 in 616ed53

	/// A built distribution (wheel) that exists in a local directory.
	#[derive(Debug, Clone)]
	pub struct PathBuiltDist {
	pub filename: WheelFilename,
	pub url: VerbatimUrl,
	pub path: PathBuf,
	}

And the second is for source distribution path dependencies:

uv/crates/distribution-types/src/lib.rs

Lines 206 to 213 in 616ed53

	/// A source distribution that exists in a local directory.
	#[derive(Debug, Clone)]
	pub struct PathSourceDist {
	pub name: PackageName,
	pub url: VerbatimUrl,
	pub path: PathBuf,
	pub editable: bool,
	}

My understanding is that the second is also used when we have a path dependency to a directory.

This all matters for the lock file because if a path dependency points to a wheel or a source dist, then we want to record a hash for it. But if it comes from a directory, then we very specifically do not want to record a hash.

So to fix this issue, I think we need to:

• Adjust the PathSourceDist type so that it indicates whether it came from a real source distribution or a directory. Possibly one way to do this is to split the type in two, with one type representing source distributions and the other representing a directory.
• Adjust the Lock data model so that distributions with a path source kind are more limited than what they are today. I think we actually do not want to encode the file path itself, and instead derive that from the pyproject.toml. (This would match what Cargo does.)

[charliermarsh]

I can look at the first bullet there, splitting PathSourceDist.

[charliermarsh]

What does the second bullet mean exactly? Can you flesh it out a bit more? Perhaps I can help with it.

[charliermarsh]

Is it that the path gets omitted entirely when it's part of the workspace?

[BurntSushi]

Is it that the path gets omitted entirely when it's part of the workspace?

Yeah exactly. Cargo rebuilds the path from the Cargo.toml instead, as I understand it. So in order to get the path of a path dependency in a lock file, I think there is some interaction point between what's in pyproject.toml and what's in the lock file.

(There is at least one other interaction point as well: finding the relevant root package in the lock file at which to start a graph traversal.)

[konstin]

Fixed by #4205, we can revisit this later if we want to omit paths