Unpacking lockfiles in different package managers

[Eric Myhre]

I somewhat agree.  It is both confusing in that "locking" is often about 
concurrency; and also it is unfortunate that "lockfile" can be ambiguous 
as to whether it's about "locking" down version selections by *name* 
(which still leaves a subsequent external(?) resolve process in play) vs 
by a hash.  The former is a confusion that is unfortunate, but 
overcomable by context; the latter is a more serious conflation that 
remains ambiguous even when fully in context.

It's also a ship that's *largely* sailed, I would be inclined to admit.  
But maybe we're also the community that has good justification to try to 
raise the bar of precision on this :)

Fwiw, in Golang, the file used for checksums/hashes is called "go.sum", 
and in their description of it in https://go.dev/ref/mod#go-sum-files , 
they manged to 100% avoid the use of the word "lockfile".

They have also a "go.mod" file which contains the version resolve. They 
call this a "build list" file.  They do use the word "lock" -- in scare 
quotes as well :) -- exactly once in their description and 
disambiguation of what this file does.  (They insist it is not a "lock" 
file, in fact. :))

I'm not sure I advocate for exactly that language from the Go tooling as 
perfect, but it's definitely an example of a sizable community that has 
pointedly, and successfully, resisted using the "lockfile" naming.

Cheers :)


On 12/10/25 2:55 AM, John Gilmore wrote:
> Is "lockfile" an appropriate term to use for these files?
>
> I think of a lockfile as something that avoids race conditions among
> multiple concurrent processes.  As in Wikipedia:
>
>    https://en.wikipedia.org/wiki/File_locking#Lock_files
>
> In this repro discussion, a "lockfile" seems to perhaps be "locking" a
> library reference in a compilation to a particular version of that
> library (and sometimes with a particular checksum on that library's
> source code?).  That is an unusual use of the term "lockfile".  I
> wonder if we could consider adopting a less confusing term.
>
> Thanks!
>
> 	John
>
>