Let’s take wheels as an example. There is package.wheel.name, package.wheel.path and package.wheel.url. None of those are exclusive, so any combination can be set. The question that has come up thanks to @sbidoul and this PR is what if those keys disagree about file names (this also applies to sdists and archives)?
My thinking is name takes precedent no matter what, but if path and url are both set but not name and there’s a conflict with the file name then the lock file is rejected for being ambiguous. You could argue sdists are a special case since the file name doesn’t contain critical metadata thanks to package.name and package.version, but “Special cases aren’t special enough to break the rules”.
So my questions are:
Do people like what I’m proposing?
If so, is this just a doc update, a version bump on lock files, or a PEP-level change?
Sounds reasonable to me, and I think this can be just a doc update, because the problematic scenario should (as far as I can see) not happen in normal usage, it would take special effort to construct a lockfile that was inconsistent like this.
In fine with this rule for wheels, and for sdist as well, for symmetry.
For archives I’m less sure as there is no package.archive.name field and the archive name is normally not relevant, so if it differs for path and URL it should not matter in practice.
This also makes me think we should validate that names of package.wheels[] and package.sdist are consistent with package.name and package.version. I would also suggest that as a doc update.
What if something went horribly wrong and the URL says spam-1.0.tar.gz and the path said spam-1.0-py3-none-any.whl? Now you don’t know how to install the file (you don’t even know the file format). Otherwise I’m not sure how I would work with archive files from an installer perspective.
That I’m less concerned about as it doesn’t impact installation. But I would be okay making that a “SHOULD” if @pf_moore is since it’s a cheap consistency check.