[lobster_johnson]

> 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 complexity of the problem space. Developers tend to brush off package management as being simple. But once you include range-based version constraints and transitive dependencies, it gets a bit messier. Look at NPM and Yarn; they're still struggling to get all the details right. On the other hand, there's Ruby's Bundler. It came out in 2009, RubyGems in 2004, and I've never had a single issue with the toolchain (other than messing up my own constraints). I don't know what kind of magic elixir they were drinking, but somehow those guys managed to nail it from day one.

[Lazare]

> Look at NPM and Yarn; they're still struggling to get all the details right.

I think that's a bit unfair. NPM has been a horrible package manager in a multitude of ways since day 1. My default assumption if it gets something wrong it isn't because it's hard, but because npm gets a lot of things wrong.

Yes, RubyGems got it right, but so did Composer. And Cargo. And every other language specific dependency manager I've used in over a decade. The lesson I'm drawing isn't that dependency management is uniquely hard, it's that npm is uniquely bad. :)

[gkya]

Comparison to NPM is also unfair because of the rather unique community around it.

[oceanswave]

Putting NPM on a pedestal of badness is unfair. NuGet deserves to be right up there next to it, but also holding the bouquet and wearing the tiara and waving to the crowd

[gkya]

Simpler does not mean better. ed(1) is definitely simpler than any text editor out there. DOS is simpler than any modern OS out there. Yet we use none of these because complexity is needed for sophistication.

[BurningCycles]

>Simpler does not mean better.

Doesn't mean worse either. If it solves the same problem as dep in a less complex way I'd say it's better, if it actually does is something we'll see once it sees adoption.

[sethammons]

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 broke what. When I heard about using the Minimum Version Solver, my first thought was how that would have saved me so much time during my Cookbook Version wars.

[lobster_johnson]

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