Lock files, again (but this time w/ sdists!)

[radoering (Randy Döring)]

@pf_moore

But index lookup, and filtering it to a list of known files, is a side issue compared to my main point here, which is that if the installer still has to do a full dependency resolution (regardless of whether it’s on the full index or a filtered one) then that’s not (to me, at least) “locking” the solution.

Although Poetry currently does a resolution restricted to the locked package versions when installing, I believe it would be possible for a universal resolver like Poetry’s to add the resulting marker conditions for each locked package/version to the lock file. (Marker conditions for two versions of the same package will be mutually exclusive.) Then, the installer only has to evaluate the marker condition of each locked package/version to decide if it’s relevant for the target environment. It only has to choose the best of the locked distribution files of the relevant locked package versions. In other words, I believe it is possible for a universal resolver to create a lock file so that the installer does not have to do a resolution, only evaluate marker conditions and choose one of the locked distribution files. That’s my vision of an environment-independent lock file.

@sirosen

I believe that poetry takes this approach because it supports dependency groups

OK, I forgot dependency groups in the previous paragraph. But I think, it’s the same. We don’t do it but it might be possible for a Poetry-like resolver to track (and lock) which groups require a locked package.

@rgommers

Standardization in a PEP also usually means pressure on tool authors to adopt that way. I can imagine Poetry & co adopting this lock file type in addition to what they already provide, but I don’t see them breaking their current users by dropping what they already have.

I absolutely agree. We might export the standard format for other tools if the demand is high enough but probably will not use it for ourselves.