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

121–130 of 138 posts

Re: The vgo proposal is accepted. Now what?

#121

Post by lobster_johnson »

sethammons wrote: post #118
lobster_johnson wrote: post #56

Earlier quoted context omitted.

> Now Cox's solution might indeed be better (though I think it's an overkill ... vgo is actually much, much simpler than dep. The sheer number of words in Russ Cox's series of blog posts belies its simplicity. vgo doesn't need a SAT solver. If you look at many of the issues dep is struggling with, they're related to solving N libraries with transitive dependencies up the wazoo. Cox's long treatise reflects the comple…

I'm having a hard time rectifying the "Ruby's Bundler"+"solved problem" axiom. Take my experience with Chef. It is Ruby. Berkshelf is supposed to solve cookbook versions, but you can use bundler around that. As a "not-a-ruby" guy, it is all a bit confusing actually. All I know is that Bundler and Berkshelf have caused me untold issues. Never resolving dependencies that leads to manually finding what version update br…

I've not used Berkshelf, but I suspect your problems were related to Chef and the fact that they've built their own dependency system that also interacts with Bundler/RubyGems.

Anecdotally, my company has used Ruby since around 2004, and Bundler since its first release, and we never had any issues. That doesn't mean nobody has ever had any issues (clearly! [2]), but it generally seems like Ruby package management is a solved problem, and that it would be a good model for any dependency system to use.

Bundler does have one feature (or misfeature) that Russ Cox criticizes: "bundle install some_gem" can cause unrelated gems' minor (or maybe it's minor) versions to be upgraded even if you don't tell it to. I've never liked that, and would much prefer to use "bundler update" to perform explicit upgrades. But I don't think that behaviour is at all tied to its solver, or that MVS is needed to fix it.

[1] https://github.com/bundler/bundler/issues/5068

[2] https://github.com/bundler/bundler/issues

Re: The vgo proposal is accepted. Now what?

#122

Post by amluto »

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…

> while vgo would (correctly) start using the new version because of MVS.

I disagree with the “correctly” part. MVS seems to pick up a newer version mostly by accident. If you’re relying on a transitive dependency to trigger a security update, you are doing it very wrong.

Re: The vgo proposal is accepted. Now what?

#123

Post by skybrian »

oceanswave wrote: post #112
skybrian wrote: post #58

Earlier quoted context omitted.

Yes, you are right. And I believe vgo is supposed to guarantee reproducible builds just like other package systems. However, when you upgrade a dependency, it's still possible that you're using a particular combination of library versions that have never been tested before. Some incompatibilities can be prevented by looking at version constraints. But you're not left with no error detection if the package system fail…

This methodology places way too much emphasis on the breadth of the tests into a test centric view— say you had a dep that had an SSL vulnerability - most of the time you’re not going to be checking for this type of thing at the level of your app, and doing so - but you bet you need to ensure that you are using the version of the dep that has the vulnerability fixed

I'm not sure they're entirely distinct. For example, if the SSL library exports a constant containing a version number, you could write a test asserting that it's not the bad version.

It's not as good as testing for the vulnerability, but then again no form of version number checking does that. (This is similar to the principle in web development that feature detection is better than version string checking. But sometimes version-checking is the best you can do.)

Checking version numbers in the package system allows for much faster backtracking, making it feasible to try many versions and select a combination that (hopefully) works. But verification can be done using testing.

Re: The vgo proposal is accepted. Now what?

#125

Post by iambvk »

kibwen wrote: post #79
iambvk wrote: post #69

Earlier quoted context omitted.

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.

I'm not sure what this is asserting. There's no association between MVS and build infra. If you have a security fix to apply, you'd run `vgo get -u` to upgrade all your modules; systems like Cargo that use lockfiles would run `cargo upgrade`. This is just as automatic. In fact, vgo is less automatic here because systems like Cargo allow users to decide when they want certain upgrades automatically, which means that n…

> if the upgrade requires a major version bump then you also have to edit the import statements in your source files as well

As per vgo blog posts, this scenario is not an Upgrade, but replacing one package with another package. A package is uniquely identified by it's import path, so if major version is changed, import path changes, so it is not same package.

Re: The vgo proposal is accepted. Now what?

#126

Post by eridius »

sseth wrote: post #107
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.

Most package managers ignore the lock files of the dependencies when picking up versions - they only use the lockfile of the topmost project for picking up versions. The big difference with the MVS strategy in vgo is that the dependency list of a dependency is actually used to determine the version. If package A uses B, which was tested with v1.2 of package C, you will get v1.2 of C, even if there is a later version…

I think package managers should have an option to run a build of your package using the oldest versions instead of newest versions, just to validate that the build works, but that this shouldn't be the normal way to resolve dependencies.

Re: The vgo proposal is accepted. Now what?

#127

Post by matte_black »

sethammons wrote: post #119
oceanswave wrote: post #115

Earlier quoted context omitted.

So go is about recreating the wheel, over and over again

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?

Re: The vgo proposal is accepted. Now what?

#128

Post by ljm »

weberc2 wrote: post #23
ljm wrote: post #17

Earlier quoted context omitted.

Quite the contrary: NPM's reputation in these circles is less than stellar and it's been incumbent in the JS ecosystem ever since Node became a thing. Well, with a few attempts at competition along the way before those working with the browser jumped on board, but nobody is pushing anybody to use anything but NPM and that attitude hasn't changed for years. This story isn't unique to Go: both Python and Ruby have had…

> Maybe Go's mistake is searching for the one-true dependency resolution system and deprecating everything along the way until something good-enough turns up. Maybe it'd be better that developers are encouraged to use dep while vgo is still in proposal stage so that there is an easy migration path from one standard to another, as opposed to immediately rendering obsolete. The odd thing is I get the feeling that their…

Feels like Go is trying to carve its own path, for better or worse, against conventional wisdom. Plan9 was pretty much the same in a lot of ways and it came up with some really interesting concepts (that sadly haven't panned out that well - I'd love to see a modern OS attempt at Acme, I found that incredibly intriguing and I actually wonder if it could be revived in VR.)

If they come up with something innovative with vgo then great. It's just a shame that the community is opting for a monopoly on the system before it even physically exists. They should be encouraging dep to thrive while doing this experimentation on vgo behind the scenes, because then at least they've got community alignment on dep and not dep, glide, godep, `git clone some-repo vendor/some-repo`, `go get` and whatever else you can do to pull in external code.

Re: The vgo proposal is accepted. Now what?

#129

Post by weberc2 »

ljm wrote: post #128
weberc2 wrote: post #23

Earlier quoted context omitted.

> Maybe Go's mistake is searching for the one-true dependency resolution system and deprecating everything along the way until something good-enough turns up. Maybe it'd be better that developers are encouraged to use dep while vgo is still in proposal stage so that there is an easy migration path from one standard to another, as opposed to immediately rendering obsolete. The odd thing is I get the feeling that their…

Feels like Go is trying to carve its own path, for better or worse, against conventional wisdom. Plan9 was pretty much the same in a lot of ways and it came up with some really interesting concepts (that sadly haven't panned out that well - I'd love to see a modern OS attempt at Acme, I found that incredibly intriguing and I actually wonder if it could be revived in VR.) If they come up with something innovative with…

> If they come up with something innovative with vgo then great.

For sure, but I actually like Go and I'm unnerved that none of the concerns raised by folks like Sam (read "folks with experience in package management") are being addressed. This approach doesn't inspire confidence in vgo.

Re: The vgo proposal is accepted. Now what?

#130

Post by Groxx »

blaisio wrote: post #62
kibwen wrote: post #55

Earlier quoted context omitted.

> The standard answer is lock files which is extra bloat and leads to merge conflicts. Bloat how? A lockfile is a handful of bytes. A thousand lockfiles could fit in the space of a single Go hello world binary. And I've never heard of a merge conflict from a lockfile. What are the actual arguments against lockfiles?

It's pretty easy to get a merge conflict from a lock file. If two developers add a dependency and then try to merge their changes together, it can happen easily.

That's correct behavior though - you can't merge "upgrade A" and "upgrade B" in isolation with literally any confidence that it works.
Post reply on HN