diazona@techhub.social (@diazona@techhub.social)
Software engineer, former particle physicist, occasional blogger. I support the principle of cake.
Posting habits: ~80% #Monsterdon, ~10% #Python/#tech, ~10% funny/uplifting/entertaining content. Rare politics-related posts, always using popular hashtags so they can be filtered out. I typically don't boost posts with images unless they have #AltText.
#books #bookstodon #reading #scifi #fantasy #programming #C #CPlusPlus #Linux #Git #KDE #bash #fedi22
Post
-
PSA: go.sum is not a lockfile.
Senza categoria@brouhaha @filippo Ah yeah, I see how that'd make sense.
I should add, too: my previous post is based on my understanding of the word "lockfile" in a packaging context, but I suppose other packaging systems might use the term differently.
-
PSA: go.sum is not a lockfile.
Senza categoria@brouhaha @filippo That's a different meaning of lockfile (or lock file).
In software package management, when you tell an installer to install one or more packages by name (possibly with some version constraints), it will choose versions of the packages you named and all their (direct and indirect) dependencies and install those versions. But you don't know which versions it's going to choose. There are thousands/millions/billions/... of possible ways to choose the version of every package that needs to be installed, and typically that includes a lot of choices that wouldn't even work. So people have developed tools that take as input a set of package names and optionally version constraints and spit out a list of one *specific* version of every package in the dependency graph. This is called "locking dependencies", and if the versions are recorded in a file, that is a lockfile. Developers can then test that specific combination of dependency versions and confirm it works.
-
PSA: go.sum is not a lockfile.
Senza categoria"what does 'being done from a lockfile' mean in this context?": You have a program which is capable of installing packages. How do you tell it which packages to install? When I say "being done from a lockfile", I mean that the way you tell the program which packages to install is by giving it a lockfile. (As opposed to, say, giving it the name of a package.)
"You are in xxx. You add foo. Which version of bar do you get? The latest or the one in foo’s lockfile?": What does it mean to be "in" xxx? Based on previous messages, I thought xxx was a package?
P.S. not trying to be difficult here, I'm just genuinely confused
-
PSA: go.sum is not a lockfile.
Senza categoria@filippo Is this about lockfiles? If the installation is being done from a lockfile, then it's whichever version of bar is specified in the lockfile. Otherwise, depends on the resolver and how it's configured, but probably the latest available version of bar, if there's no further constraint on its version.
I'm not sure I see where you're going with this.
-
PSA: go.sum is not a lockfile.
Senza categoria@filippo Yes I read that post; that's what helped me understand enough to formulate my question. It's about npm, and maybe npm does lockfiles differently, I wouldn't know, but what he's saying there does not accurately describe how any of the Python installers I'm familiar with handle lockfiles.
-
PSA: go.sum is not a lockfile.
Senza categoria@filippo Interesting stuff
One nitpick, or perhaps more likely a misunderstanding on my part: I wasn't sure what you meant by lockfiles applying recursively, but if that's referring to pinning the indirect dependencies of the main package, then at least in Python, they *do* apply recursively - at least as far as I understand it, a lockfile is supposed to specify exact versions of every dependency all the way down the graph. The idea is that if you install the exact packages listed in the lockfile and no others in an empty environment, everything should work. Or did you mean something else by applying recursively?