Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The vgo proposal is accepted. Now what?

research.swtch.com

Post reply on HN
Print view View original

131–138 of 138 posts

Re: The vgo proposal is accepted. Now what?

#131

Post by Groxx »

nicpottier wrote: post #27
adwhit wrote: post #2

For those who missed it, Sam Boyer (maintainer of dep) wrote a detailed post about why he thinks vgo (or rather Minimum Version Selection) is inadequate[0]. The key argument is With dep, it’s usually easy to point to failures - they’re explicit, verbose (and, currently, often difficult to understand, and printed out at the end of a dep ensure run. The primary failure mode in vgo, however, is silent false positives -…

They haven't been addressed, but then again they exist in `dep` as well and most other package managers, just in different forms. Russ Cox had a good talk about this which is worth a watch: https://www.youtube.com/watch?v=F8nrpe0XWRg&feature=youtu.be...

>They haven't been addressed, but then again they exist in `dep` as well and most other package managers, just in different forms.

The whole premise of the blog post is that vgo has additional failure modes that other ones do not. Right at the top, the first item in the list of "what this post covers" is:

>MVS has all the same failure modes, plus more, minus pathological SAT.

Re: The vgo proposal is accepted. Now what?

#132

Post by Lazare »

sseth wrote: post #117
Lazare wrote: post #89

Earlier quoted context omitted.

> 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 whe…

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 ve…

Umm. But we started with this:

> Those choices are stable, without a lock file. This is what I mean when I say that vgo's builds are reproducible by default.

You say:

> 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.

That seems to contradict Cox's assertion? If I get a newer version of C automatically when B updates, because I'm automatically getting a newer version of B, then I no longer have reproducible builds; the answer to what version of B I'm using would have "change[d] as new versions were added.", which is the thing Cox is saying vgo prevents.

But my understanding of vgo is that this is actually wrong; I don't get the new build automatically at all; I get it when I update using `vgo get -u`. Which is...the same as using Cargo (Composer, Bundler, Yarn, etc.) right? I eventually run the appropriate update command, the solver runs, and I get the new version of B and C.

Ultimately it feels like a dependency management tool can either lock me in to my current versions until I manually trigger an update to get bug fixes, or it can transparently update things in the background as new compatible versions are released.

I take Cox to be asserting that vgo does the former and Cargo does the latter, you seem to be asserting that vgo does the latter and Cargo does the former, and my understanding is both do the former. It feels like this shouldn't be this confusing to explain what vgo is trying to do. :)

Re: The vgo proposal is accepted. Now what?

#133

Post by marcus_holmes »

matte_black wrote: post #127
sethammons wrote: post #119

Earlier quoted context omitted.

Not really. Generally, the wheel you need and the wheel I need are a bit different. Instead of using some bloated "all-wheel," developers choose their custom wheel. Simple example, SyncMap. This is a general purpose all-wheel, and as such, due to Go's type system, you have to use runtime type assertions against it. If I need a lockable map, I just make one and it is of the type I need, say map[string]*Foo. I just wra…

What is the Go alternative to generics?

specifics?

Joking aside, that's pretty much it. The usual method for go devs is to solve the specific problem in front of you (and accepting a certain amount of duplication) rather than creating generic solutions that have a wider scope than they need. Once it's all working, refactoring can often remove the duplication and provide a better solution than the generic one would have provided (because by then you know the problem domain better).

I've been coding in Go for a few years, and only a couple of times run into the "shit, I need generics here" problem.

And yes, I get that this means that the Go answer to generics is "you don't need generics" ;) Which sounds like such bullshit of course.

Re: The vgo proposal is accepted. Now what?

#134

Post by sseth »

Lazare wrote: post #132
sseth wrote: post #117

Earlier quoted context omitted.

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 ve…

Umm. But we started with this: > Those choices are stable, without a lock file. This is what I mean when I say that vgo's builds are reproducible by default. You say: > 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. That seems to contradict Cox's assertion? If I get a newer version of C automatically when B updates,…

I was not clear. If you say vgo get B@latest in A, you will get the correct version of C. If you do not pull in the latest version of B, you would not get that.

The thing I like about this is that for many transitive dependencies such as C, i do not want the absolute latest version - i would prefer the version of C that B was tested with at time of release. I can override this of course, but this is the default behavior i like.

Re: The vgo proposal is accepted. Now what?

#135

Post by stubish »

kaeshiwaza wrote: post #93
stubish wrote: post #87

Earlier quoted context omitted.

Third party tools will still be necessary, to work around short comings. I imagine a tool to update all your imports to the latest release will be needed by the majority who don't need reproducible builds, so you get versions with known bugs fixed. MVS seems to be essentially pinning to the oldest possible version, and having that entrenched in your software is going to suck the big tech debt when you do need to upda…

Look at https://research.swtch.com/vgo-tour (Upgrading) vgo list -m -u will show you which newer releases of your dependencies. Then you can upgrade one dependencies vgo get xxx or all vgo get -u

Excellent, that seems to address my misgivings. Thanks.

Re: The vgo proposal is accepted. Now what?

#136

Post by sametmax »

jcelerier wrote: post #92
pcx wrote: post #64

Earlier quoted context omitted.

> The speed of the solver is not a problem in any other package management system I've seen This! I've never heard anyone complain about this aspect of a package manager, EVER. vgo seems to be optimizing for a problem no one has.

> The speed of the solver is not a problem in any other package management system I've seen really ? It has been a large problem in Debian for instance and has enabled a lot of research ( https://scholar.google.fr/scholar?q=debian+solver ). One of the reason for Fedora's yum -> dnf change was also a change of solver. It's a hard problem that affects a lot of people.

You can't compare languages and os package manager. They are on a completely different scale.

Re: The vgo proposal is accepted. Now what?

#137

Post by eridius »

petre wrote: post #103
lilyball wrote: post #67

Earlier quoted context omitted.

The "minimal versions" strategy basically just replaces the lockfile with your dependency list. Two branches want to update the same dependency? With a lockfile, they both update the lockfile and will have a merge conflict (assuming the updates aren't identical). With "minimal versions", they both update the file that declares the dependency, and, you guessed it, have a merge conflict.

Minimal versions put the burden of background compatibility on the maintainer of the dependency. If such is the case, library maintainers are constrained to refrain from breaking background compatibility at minor version changes, like Go itself does. In this case, you can merge, resolve the conflict by incrementing the dependency's version number, rebuild and retest and if all goes well commit. With lockfiles if bran…

SemVer already solves that problem.

Re: The vgo proposal is accepted. Now what?

#138

Post by asymmetric »

pcwalton wrote: post #72
baq wrote: post #71

Earlier quoted context omitted.

i've seen aptitude get really confused about what to install and computing a solution for a few minutes. once. 10 years ago or so, i don't even remember.

I should clarify that I'm referring to language package managers. Their problem domains are significantly different than those of system package managers.

I'm curious, what makes the problem domains different?

I'm asking because I'm interested in "universal" package managers like nix.

Post reply on HN