Always require hashes for wheels in lockfile

[charliermarsh]

Summary

I think we do always want hashes for wheels (since a wheel is a zip file -- we can always hash it). But hashes are optional for source distributions: if we have a Git repo as the source, there's no way to compute a hash of it in the standards.

In general, if the user ends up needing to build from source, then we compare the hash of the source; if they use a pre-built wheel, then we compare the hash of the wheel.

[BurntSushi]

Hmmm the purpose of this test was to check a case where a hash is given but should not be present. And the purpose of the test above was to check a case where a hash is missing but should be present. i.e., They should both be checking error cases.

[BurntSushi]

So I basically agree with the end effect here, but I don't think this is actually internally consistent. The reason why I made it possible for hash checking in wheels to be optional is because this is what the data model currently supports:

uv/crates/uv-resolver/src/lock.rs

Lines 739 to 745 in eab2b83

	fn from_path_dist(path_dist: &PathBuiltDist) -> Wheel {
	Wheel {
	url: path_dist.url.to_url(),
	hash: None,
	filename: path_dist.filename.clone(),
	}
	}

The problem here, as far as I can tell, is that not all "built" distributions have hashes attached to them. So when they make it to the lock file data structure, there's no hash to include.

What this means is that this checking will reject lock files that can be generated right now.

With that said, I do agree that this change is, I think, what we want our end state to be. I don't think I feel strongly about whether we do the stricter checking now, but I did kind of feel like the checking should be consistent with our serialization. If not, then perhaps a comment here explaining the inconsistency would be helpful.

[charliermarsh]

I agree with what you wrote.