A response about dep and vgo • Hacker News Board

Re: A response about dep and vgo

#81

Post by jessaustin » Sat, Jul 28, 2018, 2:07 AM UTC

nathancahill wrote: post #48

Athas wrote: post #38

Earlier quoted context omitted.

There are lots of small differences, but I would say there are two major: * Semantic Import Versioning. A package is identified by some name. I think vgo calls it an "import path", but I have also seen "package path" used. Every version of that package must remain compatible with previous versions. You may not break compatibility (i.e. increment the major semver number) without also renaming the package. There is som…

> vgo tries to install the oldest version of a packages that still satisfies any lower bounds This alone would make npm 100x less painful to use.

You don't have to use operators in package.json, so this pain relief is available to you right now. Just let the version remain precisely as "npm install" wrote it, with no tildes or wildcards or anything.

Admittedly, the "update all packages to latest compatible version" flag described above sounds very nice. There is approximately zero chance the npm developers would ever accept such a PR, but there would be nothing wrong with a utility that accomplished the same thing.

Re: A response about dep and vgo

#82

Post by faitswulff » Sat, Jul 28, 2018, 2:14 AM UTC

Athas wrote: post #17

Vgo has certainly been a disaster from a communication and community point of view. From an outsider perspective, it looks like a case of maintainer arrogance, and it is hard to believe that Go really has needs that are significantly different from those of e.g. Rust or Java. However, I am also in the unusual position that I had to design and implement a package manager for my own little language recently. My origina…

That's just the thing, right? It seems to be a clearly superior technical solution, but it has thoroughly failed from the perspective of human relationships.

Re: A response about dep and vgo

#83

Post by jessaustin » Sat, Jul 28, 2018, 2:25 AM UTC

munificent wrote: post #67

nicpottier wrote: post #40

Earlier quoted context omitted.

Open Source is absolutely chock full of examples of this.

That's survivorshop bias. Yes, occasionally a fork takes over. It very rarely succeeds and usually only in cases where the original is so toxic that it cancels out its own network effects. node.js is a good example of that. And then even there note how they eventually unforked.

It is really uncharitable to describe the node fork as "so toxic". People disagreed, but there's nothing wrong with that. I felt like the subsequent "merge" happened fairly quickly and with minimal drama.

Also this seems like a misuse of the term "survivorship bias". You claimed upthread that forks don't work because of network effects. The response was "some forks work". That is a direct refutation, no matter what the percentages are. Besides, you're misunderstanding the varied purposes of forks. I have several forks right now, not because I hate the original maintainers but because it was convenient to change a small thing for my own purposes. Whether or not upstream eventually agrees with me, my fork "works" perfectly well.

Re: A response about dep and vgo

#84

Post by jessaustin » Sat, Jul 28, 2018, 2:29 AM UTC

sagichmal wrote: post #54

claydavisss wrote: post #35

Earlier quoted context omitted.

A competition still has to be judged by someone. The only curious element here is that a (the?) judge also had the winning entry. Russ claims he got buy-in from the other core members and so far no one has contradicted that. AND...vgo is better than dep. Let's not forget that. Peter can hem and haw about politics but in the end the best horse won. Go developers want the tools to be as good as possible, 99% of them do…

> AND...vgo is better than dep. Let's not forget that. Facts not in evidence.

After reading TFA, which tries to be self-serving but is mostly just silly, do you even doubt it? I say this as someone with no dog in any Go fight. When the defendant's own testimony convicts himself, he's guilty.

Re: A response about dep and vgo

#85

Post by jsd1982 » Sat, Jul 28, 2018, 2:32 AM UTC

h8liu wrote: post #77

jsd1982 wrote: post #32

I am not involved in this discussion and have no skin in the game, but from an outsider's perspective it seems that Russ laid out exactly what his concerns were about showstoppers in the dep implementation and those concerns were effectively ignored by the dep committee. What were they expecting to happen after that? Are there some other non-showstopper classified concerns that Russ should make up on the spot and hav…

I think the issue is that Russ should have clearly told the dep people that if the showstopper issues are not handled, then he will seek for some other solution, e.g. build one by himself. However, what happened was that he told the dep people "I will build a dep tool myself to understand more on the problem details", which implies "after I understand more, I will come back to you and discuss more", but not "after I…

If I were in Russ's shoes and I had told someone as politely as I could that their solution exhibits what I consider showstopper issues, I wouldn't expect to have to clarify that I find that solution entirely unacceptable and flawed from its very design. There's no issue in the clarity of communication when the term 'showstopper' is thrown around.

Russ said he was going to go and build a tool to understand the problem better. In no way does that imply that any lessons he learns from the implementation must be communicated back to the dep committee. But for the sake of argument, let's say that did happen. Then what? Does Russ practically force the dep committee to implement vgo out of the remains of dep? Why would he do that when he just spent a month or two implementing vgo from scratch? Why bother going back to a problematic group that doesn't believe their core issues are showstoppers? If that difference of perspective exists and they're not willing to debate that, to say nothing of the fact that they feel that they should be on the receiving end of the burden of proof, what more can be gained from them from Russ's perspective?

Re: A response about dep and vgo

#86

Post by jessaustin » Sat, Jul 28, 2018, 2:41 AM UTC

h8liu wrote: post #77

jsd1982 wrote: post #32

I am not involved in this discussion and have no skin in the game, but from an outsider's perspective it seems that Russ laid out exactly what his concerns were about showstoppers in the dep implementation and those concerns were effectively ignored by the dep committee. What were they expecting to happen after that? Are there some other non-showstopper classified concerns that Russ should make up on the spot and hav…

I think the issue is that Russ should have clearly told the dep people that if the showstopper issues are not handled, then he will seek for some other solution, e.g. build one by himself. However, what happened was that he told the dep people "I will build a dep tool myself to understand more on the problem details", which implies "after I understand more, I will come back to you and discuss more", but not "after I…

"Showstopper" is a word with a specific meaning in software development. If your customer tells you about a showstopper and you ignore it, that is bad.

Re: A response about dep and vgo

#87

Post by kasey_junk » Sat, Jul 28, 2018, 2:41 AM UTC

nicpottier wrote: post #13

stcredzero wrote: post #11

Earlier quoted context omitted.

Ya, I've been following all this drama since the vgo proposal and I also find it somewhat rich...On another note I hope this is the last we hear about all this, please lets move on. I only became aware of this by going to a meetup and seeing a talk. I just want something that's workable and not broken. The reason BDFLs are in the position of making that decision is because they have proven through the accumulation of…

Note that Russ isn't going against the community, he's just going against `dep`. Most of the community, myself included is pretty psyched about go modules. Note also that the risk you propose for bad decisions is mitigated for Open Source. If that decision really turns out to be so bad then it will be forked and a wiser leader(s) will have their shot at decision making. `dep` isn't squashed! You are free to continue…

> Most of the community, myself included is pretty psyched about go modules.

Citation needed. In my corner of the community this is a very contentious issue.

The golang dependency management story has been a disaster for years. Nothing about the modules or vgo story have seemed to solve that.

In fact, its Russ who seems to be going against the norms of the community. Choosing cutting edge and untried technologies, over well understood and tested ones. If he was going to get edgy with his leadership decisions couldn't he have done it somewhere more valuable like cleaning up the type system?

Re: A response about dep and vgo

#88

Post by DannyBee » Sat, Jul 28, 2018, 2:58 AM UTC

There's an interesting discussion about this with russ and peter participating over on reddit here: https://www.reddit.com/r/golang/comments/92f3q1/peter_bourgo...

Re: A response about dep and vgo

#89

Post by pcwalton » Sat, Jul 28, 2018, 3:00 AM UTC

Athas wrote: post #17

Vgo has certainly been a disaster from a communication and community point of view. From an outsider perspective, it looks like a case of maintainer arrogance, and it is hard to believe that Go really has needs that are significantly different from those of e.g. Rust or Java. However, I am also in the unusual position that I had to design and implement a package manager for my own little language recently. My origina…

I've never seen Cargo errors be incomprehensible. Solving versions just isn't a problem in practice. Minimal version selection optimizes for convenience of the package manager implementer at the expense of the users. To me, that's the wrong trade.

Re: A response about dep and vgo

#90

Post by pcwalton » Sat, Jul 28, 2018, 3:03 AM UTC

kjksf wrote: post #63

necubi wrote: post #58

Earlier quoted context omitted.

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.

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

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