The vgo proposal is accepted. Now what?

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 - a vgo {get,test,run,build} command changes your dependency graph, and exits 0. Maybe everything’s fine, maybe it isn’t, but it’s incumbent upon you to take additional steps to understand that your build is broken.

I haven't been following this debate very closely, and this post doesn't make it clear - have these points been addressed? Is there still room to maneuver, or is the design mostly settled now? I know the post states that any design flaws will be fixed, but it sounds very much like the more typical lock-file + solver solution has been definitively decided against.

[0] https://sdboyer.io/vgo/failure-modes/

I still wonder why solving a solved problem took so long to solve for the Go community, given they already solved it anyways?

That is, in more proper words, first of all, language specific package management is mostly a solved problem. There are possible improvements, and maybe vgo realises some of them, but that's mostly a bikeshedding problem. What users need is to be able to declare what packages they need, in what version range. And their search for an alternative to fetching source repos is like searching for the cure to ilnesses that already have proven vaccines: you just put up a server and fetch from there. Decentralisation? Put up mirrors.

Then the way this vgo thing happened is the opposite of nice. Tools already existed, and they had to conform to the restrictions of the project (like the, excuse me but, idiotic idea of a $GOPATH); but then one of the Go deities come around and goes, um, I deprecate all of you, break the rules that you had to comply, and because I-am-who-I-am, this is the way to go.

Now Cox's solution might indeed be better (though I think it's an overkill, and do agree to Boyer's articles I read), but this is not the way to run a community. From my PoW, this would not preclude me from using the language if it came up, but I'd definitely be reluctant to send patches to them. Communities with deities and dogmas are always unhealthy. Those that also, additionally, are deep down in yak shaving and bikeshedding are even more so.

> Now what?

I keep using dep for as long as it's reasonable for me to do so, because I don't like MVS and I don't like how MVS has been basically forced upon us.

It seems a little unusual for Go because they've generally gone with a good, simple, and well-proven model for things. That's sort of the whole appeal: the good kind of boring. I don't really see the point of the bikeshedding they're engaged in now, and they've made the upgrade path for everyone who's been working under dep, and glide before that, more difficult than it needs to be. The rationale behind it isn't really very solid IMO either. But I suppose I am just a mere mortal, so how I could I possibly understand?

Had vgo not included MVS I think they likely would have. But there's a lot of disagreement over the design of vgo which could have been avoided had it just done what almost every other recent package manager has done. This is going to make it more painful than it ought to be, but ultimately since this will be the official solution I think it's likely that it will be adopted and that the churn will end since third party tools are no longer necessary.