[Athas]

I think reproducible builds are more important than having security problems fixed behind your back. It's not like vgo makes it hard to upgrade all dependencies to their most recent version - it's done automatically with a single command, if you want it.

[necubi]

Other package managers (cargo, gemfile, etc.) also give reproducible builds by using a lockfile. Upgrading dependencies to their maximum version is an explicit action (cargo update). It's not clear to me why the go team things lockfiles are a huge issue.

[kjksf]

Lock files also remove the "silent security fix" that was touted as the benefit of other systems.

You can't have it both ways.

You either get reproducible builds (by default with vgo, by adding lock files in other systems) or you get silent upgrades that potentially fix security issues (but also potentially introduce security issues).

You also mis-characterize the position of vgo creator. He doesn't think that lock files are a huge issue per se.

The difference is in default behavior of the system: vgo by default picks predictable, consistent version of dependencies. That version doesn't change if dependencies release new versions.

In fact, it's not just the default behavior but the only behavior.

Other systems allow specifying complex rules for which version of dependency to pick and they all allow for a scenario where you run the same algorithm over the same rules but pick different version because in the meantime some dependency has released a new version.

It's such a big problem that all those system end up introducing lock files, which is a tacit admission that what vgo does by default is a good idea.

vgo doesn't need lock files to get the benefit of lock files, which is a nice cherry on top but the real advancement is in changing the default behavior of how resolving versions of dependencies work.

[pcwalton]

> Lock files also remove the "silent security fix" that was touted as the benefit of other systems.

That is the great thing about lock files. You don't have to check them in. If you want reproducible builds, you do check them in. If you don't, you don't. The user, not the package manager, gets to make this choice on a case-by-case basis.

> The difference is in default behavior of the system: vgo by default picks predictable, consistent version of dependencies. That version doesn't change if dependencies release new versions.

And that right there is the problem. You don't get the latest version unless you explicitly ask for it. This makes the user do what a package manager is perfectly capable of doing. It thrusts the problem onto the user instead of applying a well-known solution that was causing problems for nobody.

If you are writing an application, don't you want your transitive dependencies to get security fixes without having to trawl through the tree?

[Nullabillity]

Lockfiles have other benefits, such as locking down dependencies' hashes to prevent future tampering.

[kaeshiwaza]

You'll find a go.sum with hashs of dependencies.

[jessaustin]

What you're saying makes perfect sense. This is what makes HN great. Incidentally, there's nothing about e.g. npm that would prevent this scheme: just set literal version numbers instead of using operators. The two systems definitely have different "best practices".

[pcwalton]

> It's not like vgo makes it hard to upgrade all dependencies to their most recent version - it's done automatically with a single command, if you want it.

And how does it guarantee that this actually results in anything that works, if upper bounds are not supported?

[kaeshiwaza]

Upper bound are major version, everything between should be api compatible (it's in the specs of go modules).

[pcwalton]

Except for version 0.x, and with vgo you have no recourse if somebody didn't follow the rules and made an incompatible change.

[jessaustin]

This is the whole point: just specify the version before the change, and it won't bother you.

[pcwalton]

Until someone actually wants to update their dependencies, writes "go get -u", and breaks the build.

[jessaustin]

Well sure, you probably want to test after updating all of those dependencies. That's a good reason to only update when necessary. Do you argue that some other scheme prevents bugs in dependencies? That hasn't been my experience...