Further this constraint of “lockfiles are read sequentially, and the decision about each file is taken independently of other files.” directly contradicts the specification which explicitly states there is no normative order to installation:
The following outlines the steps to be taken to install from a lock file
(while the requirements are prescriptive, the general steps and order are
a suggestion):
And even following it’s suggested installation process requires evaluating whether the package conflicts with others:
Check that no other conflicting instance of the package has been slated to
be installed; an error about the ambiguity MUST be raised otherwise.
You can not do that on a per-file basis, you must read all other files to determine if there is a conflict.
The spec records files per project, so it operates on a per project basis. But it breaks the “source” of a project into different types (directories, vcs, etc), and specific to this question, it stores wheels and sdists in separate keys, and the spec declares that you only fall back to sdist if there are no wheels listed for the project.
Interestingly though, I still think @pf_moore is actually wrong here? I don’t see anywhere in the pylock spec (both the living spec and the original PEP) that says the ordering of wheels in the pylock toml is meaningful. As far as I can tell, the spec is completely silent on the topic of what order wheels should be listed in the lock file. There is of course, an order that the wheel files are written in by nature of the whees being an array, but the spec doesn’t say anything about it, it’s just implicit in the nature of it being an array.
The spec also doesn’t say why it’s an array, other than in the rejected section which says:
One could see writing out wheel file details as a table keyed on the file name.
In general, though, people did not prefer this over the approach this PEP has taken.
Also, the only mention of how to select a wheel out of the array of wheels for an individual project entry in the spec says this (which as you called out, it says the requirements are prescriptive but order is a suggestion):
Look for the appropriate wheel file based on packages.wheels.name; if one is not found then move on to [packages.sdist] or an error MUST be raised about a lack of source for the project.
Which again doesn’t doesn’t say anything about order, just that you look for the appropriate wheel file based on name-- and arguably the wheel spec says you should install “the most specific wheel” (though it’s very vague on what that means). Absent the lock file explicitly specifying that things should be used in the order they appear in the lock file, then I’d argue that “look for the appropriate wheel file based on name” implies using your normal mechanisms for selecting which one of those N of M files is both compatible and preferred.
So I think actually, anyone relying on the ordering of wheels in the lock file to be meaningful is relying on implementation defined behavior anyways (but even if they weren’t, like I mentioned above, variants aren’t meaningfully different than non variant wheels in this aspect).