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.
It's a common source of confusion (especially among C developers), but I
also think this ship has sailed, the term is about a decade old at this
point.
The oldest reference I could find is Gemfile.lock from 2010,
composer.lock (2014), Cargo.lock (2015), Pipfile.lock (2015), yarn.lock
(2016), npm's package-lock.json (2017), .NET's packages.lock.json (2019).
The proper term is "dependency lock file" with plenty of search results,
I'm surprised wikipedia has indeed zero mentions on this. There's
https://en.wikipedia.org/wiki/Package-lock.json (which redirects to a
general npm article however).
Your best bet at this point is probably referring to these files as SBOM
and hoping it catches on[1]. This is also how I playfully refer to them
in whatsrc[2]. Using them to specify your build inputs (like cargo and
friends do, as well as .BUILDINFO) would be much more accurate than
trying to fuzzy-guess them afterwards.
cheers,
kpcyrd
[1]: Also suggested here almost exactly 3 years ago (back when I was
still posting there): https://x.com/kpcyrd/status/1601940872484261891
[2]: Random example:
https://whatsrc.org/sbom/sha256:906399c90831817e64dba301274ee8de9830028f08c2e643e3ee8273df156177
