> The lock file stops future upgrades; once it is written, your build stays on serde 1.0.27 even when 1.0.28 is released. In contrast, minimal version selection prefers the minimum allowed version, which is the exact version requested by some go.mod in the project. That answer does not change as new versions are added.
So with Cargo, you get the exact version you want, ie 1.0.27, and it won't automatically update when a new version is added. And with MVS you get the exact version you want, and it won't automatically update when a new version is added?
...either I'm an idiot, or Cox is using the word "contrast" here to mean "identically".
> Those choices are stable, without a lock file. This is what I mean when I say that vgo's builds are reproducible by default.
Yes, but Cargo uses a lock file by default, meaning that Cargo's builds are reproducible by default too?
I'm open to the idea that vgo/MVS is delivering something amazing here, but every writeup I've seen so far seems to have a miraculous ability to make it sound like a re-branding of the same features every decent package manager has had forever.
The key here is that Cargo ignores the lock files of the dependency, while vgo uses the go.mod files of the dependency.
So, if project A uses B, which uses 1.0.27 of C, then the lock file for A is locked to that version of C. Suppose B now releases a version that was tested with 1.0.28 of C, A will continue to be built with the older version because of the lock file, while vgo would (correctly) start using the new version because of MVS.
> The lock file stops future upgrades; once it is written, your build stays on serde 1.0.27 even when 1.0.28 is released.
That means that the only difference is that `vgo` doesn't require lock file for reproducible builds, now the question is what's considered so terrible wrong/dangerous with having a lock file?
If there was a security fix in a package, MVS allows build infra to automatically upgrade (assuming packages imported are well maintained by their owners) where as lock-files require manual intervention.
Imagine the packaging and development ecosystem in internet scale.
Thanks for posting this. It's much more fleshed out than my hazy memory of a GitHub comment although I still don't agree that all this effort it is worth the "simplification" of not having a lock file.
The aversion to lockfiles is especially head-scratching given that vgo has a concept of a go.modverify file (separate from the go.mod file) which is used to store version hashes, which is a function that lockfiles usually fulfill. I think the advantage is supposed to be that modverify files are optional, but in practice I don't see why anybody wouldn't want one given that it provides additional security for free.
Lazare|7 years ago
So with Cargo, you get the exact version you want, ie 1.0.27, and it won't automatically update when a new version is added. And with MVS you get the exact version you want, and it won't automatically update when a new version is added? ...either I'm an idiot, or Cox is using the word "contrast" here to mean "identically".
> Those choices are stable, without a lock file. This is what I mean when I say that vgo's builds are reproducible by default.
Yes, but Cargo uses a lock file by default, meaning that Cargo's builds are reproducible by default too?
I'm open to the idea that vgo/MVS is delivering something amazing here, but every writeup I've seen so far seems to have a miraculous ability to make it sound like a re-branding of the same features every decent package manager has had forever.
sseth|7 years ago
So, if project A uses B, which uses 1.0.27 of C, then the lock file for A is locked to that version of C. Suppose B now releases a version that was tested with 1.0.28 of C, A will continue to be built with the older version because of the lock file, while vgo would (correctly) start using the new version because of MVS.
vhbit|7 years ago
That means that the only difference is that `vgo` doesn't require lock file for reproducible builds, now the question is what's considered so terrible wrong/dangerous with having a lock file?
iambvk|7 years ago
Imagine the packaging and development ecosystem in internet scale.
eberkund|7 years ago
kibwen|7 years ago