PSA: go.sum is not a lockfile.
Uncategorized
28
Posts
9
Posters
62
Views
-
PSA: go.sum is not a lockfile.
You never need to look at go.sum.
go.mod has everything you need.
-
PSA: go.sum is not a lockfile.
You never need to look at go.sum.
go.mod has everything you need.
@filippo "then what is it?"
best guess at what could go there?
"go.sum detects tampering in transit or in your local ~/go cache, for specific tagged versions of dependencies; it isn't locked to a particular version, it's the last time you pulled & computed hashes for those tags"
-
PSA: go.sum is not a lockfile.
You never need to look at go.sum.
go.mod has everything you need.
@filippo omg thank you for this. I was *just* looking into this today, because we got some automated dependency notification that something was outdated because we had like, something v0.0.0-20201119 in go.sum even though the same package in go.mod was 0.39.0. I will link your post to say “we don't need to do anything”!
-
PSA: go.sum is not a lockfile.
You never need to look at go.sum.
go.mod has everything you need.
@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?
-
@filippo omg thank you for this. I was *just* looking into this today, because we got some automated dependency notification that something was outdated because we had like, something v0.0.0-20201119 in go.sum even though the same package in go.mod was 0.39.0. I will link your post to say “we don't need to do anything”!
@michael awesome, that’s exactly what I wrote it for!
You might want to reconsider using whatever generated that notification: if they get something so basic wrong, it’s unlikely they’ll be doing everything else right!
-
@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?
@diazona they don’t apply to dependents. Click on the linked post by Russ Cox for a full explanation.
-
PSA: go.sum is not a lockfile.
You never need to look at go.sum.
go.mod has everything you need.
when Russ Cox started publishing his research on packaging and minimal version selection, i was deep into Python packaging, writing my own package manager (DepHell), dependency resolution included. and i was honestly impressed. then we actually got it in Go and practice confirmed the theory: this is THE BEST package manager and dependency resolver ever made. if nothing else, i'd use Go just for that.
-
@filippo "then what is it?"
best guess at what could go there?
"go.sum detects tampering in transit or in your local ~/go cache, for specific tagged versions of dependencies; it isn't locked to a particular version, it's the last time you pulled & computed hashes for those tags"
@risottobias expanded a bit the part that says what it's for!
-
PSA: go.sum is not a lockfile.
You never need to look at go.sum.
go.mod has everything you need.
@filippo but there's no hashes in gomod, is there?
-
@filippo but there's no hashes in gomod, is there?
@raito correct, go.mod has the versions, go.sum is a dumb mapping of versions to hashes.
-
@raito correct, go.mod has the versions, go.sum is a dumb mapping of versions to hashes.
@filippo so I feel like you almost never need to look at go.sum except if you do use a system that allows only fixed output fetches and then go.sum is useful to predict more or less that hash, right?
-
@diazona they don’t apply to dependents. Click on the linked post by Russ Cox for a full explanation.
@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.
-
@filippo so I feel like you almost never need to look at go.sum except if you do use a system that allows only fixed output fetches and then go.sum is useful to predict more or less that hash, right?
@raito yeah, cmd/go/internal/modfetch needs the hashes when downloading contents. But essentially no one reimplements that part.
-
@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.
@diazona if you add foo to xxx’s dependencies, and foo depends on bar, which version of bar is used?
-
@diazona if you add foo to xxx’s dependencies, and foo depends on bar, which version of bar is used?
@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.
-
@raito yeah, cmd/go/internal/modfetch needs the hashes when downloading contents. But essentially no one reimplements that part.
@filippo Well, the Nix ecosystem definitely had appetite for that but the usage of dirhash made that quite hard because AFAIK it's not easy to go from dirhash to some raw SHA-256 or similar.
-
@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.
@diazona what does “being done from a lockfile” mean in this context?
You are in xxx. You add foo. Which version of bar do you get? The latest or the one in foo’s lockfile?
In Go, you get the one in foo’s go.mod. Which is why I say go.mod applies to dependents like manifests and unlike lockfiles, despite having lockfile-like precision.
-
@filippo Well, the Nix ecosystem definitely had appetite for that but the usage of dirhash made that quite hard because AFAIK it's not easy to go from dirhash to some raw SHA-256 or similar.
@raito yeah it’s a trade-off, dirhash OTOH avoids the need to stabilize the archive format, compression, and metadata including timestamps
-
@raito yeah it’s a trade-off, dirhash OTOH avoids the need to stabilize the archive format, compression, and metadata including timestamps
@filippo yep, it's fairly understandable why dirhash was chosen; unfortunately, Go (among application ecosystems) is quite unique in having solved this problem. Someday, Nix will support extensible fixed-output primitives so that dirhash can be explained to Nix and then Go modules can be natively downloaded by Nix and fed to the rest of the Go packaging machinery.
-
@filippo yep, it's fairly understandable why dirhash was chosen; unfortunately, Go (among application ecosystems) is quite unique in having solved this problem. Someday, Nix will support extensible fixed-output primitives so that dirhash can be explained to Nix and then Go modules can be natively downloaded by Nix and fed to the rest of the Go packaging machinery.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Polymarket had bets on when nuclear war might happen that were running for a while. For some reason they decided to take them down, can't imagine why, it's not like prediction markets risk creating perverse incentives or anything https://www.coindesk.com/markets/2026/03/04/polymarket-shelves-nuclear-detonation-markets-after-outcry
-
The AI Vampire https://steve-yegge.medium.com/the-ai-vampire-eda6e4f07163
In which Steve Yegge, formerly an interesting tech blogger, now of Gas Town, realizes that becoming a "10x engineer" through vibecoding is actually just transferring wealth to the bosses. Halfway through realizes, maybe there's someway for workers to... collectively... bargain? If only set theory had some term that could describe such a process.
Nonetheless, this doesn't seem to have changed the direction Yegge is pushing at all https://steve-yegge.medium.com/welcome-to-the-wasteland-a-thousand-gas-towns-a5eb9bc8dc1f
-
RE: https://mstdn.social/@theeclecticdyslexic/116169411669556587
HeliBoard è un'ottima tastiera android, foss, rispetta la privacy, la uso da anni.
Uno sviluppatore chiede aiuto per raccogliere dati sul "gesture typing" per sviluppare una libreria foss all'altezza anche per questa modalità.
Aiutiamolo!
-
Iran: quarto giorno di aggressione israelo-statunitense. israele attacca pure il libano, anche via terra
@anarchia
Levante in fiamme nel quarto giorno di aggressione militare israelo-statunitense, martedì 3 marzo 2026. Raid in corso sia sull’Iran che sul Libano, dove le truppe israeliane hanno superato il confine invadendo nuovamente via
-
@sleepingcreep @electricsheep Provo a scrivergli per avere la versione già buildata!
-
@nixCraft I think it’s good to remember that enshittification is the intent, and deskilling is part of the process.
-
@rusty_shackleford @nixCraft @jmalonzo
I’m not much of a criminal type, and pushing 60, so I’m probably not going to lead the charge. But I will cheer from afar.
-
Piantedosi: “Iran, pronti a difenderci. Nostre barriere efficaci”
@informatica
“Lo scoppio della guerra ci ha sollecitato direttamente e ci ha subito allertati. Abbiamo affrontato da subito uno scenario di rischi, con annesse contromisure per difendere i luoghi sensibili. Siamo pronti a difenderci”. Lo ha detto Matteo Piantedosi, Ministro dell’Interno, nel suo
