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

A response about dep and vgo

peter.bourgon.org

Post reply on HN
Print view View original

111–120 of 139 posts

Re: A response about dep and vgo

#111

Post by kaeshiwaza »

Nullabillity wrote: post #101
kjksf wrote: post #63

Earlier quoted context omitted.

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…

Lockfiles have other benefits, such as locking down dependencies' hashes to prevent future tampering.

You'll find a go.sum with hashs of dependencies.

Re: A response about dep and vgo

#112

Post by kaeshiwaza »

pcwalton wrote: post #108
Athas wrote: post #49

Earlier quoted context omitted.

I think reproducible builds are more important than having security problems fixed behind your back. It's not like vgo makes it hard to upgrade all dependencies to their most recent version - it's done automatically with a single command, if you want it.

> It's not like vgo makes it hard to upgrade all dependencies to their most recent version - it's done automatically with a single command, if you want it. And how does it guarantee that this actually results in anything that works, if upper bounds are not supported?

Upper bound are major version, everything between should be api compatible (it's in the specs of go modules).

Re: A response about dep and vgo

#113

Post by ithkuil »

jessaustin wrote: post #81
nathancahill wrote: post #48

Earlier quoted context omitted.

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

Yep, this is the problem with "features", when they exist somebody else will use them and you'll eventually have a dependency that does.

Re: A response about dep and vgo

#114

Post by kaeshiwaza »

pcwalton wrote: post #107
DannyBee wrote: post #95

Earlier quoted context omitted.

I'll present a counterpoint of a different kind, since everyone is arguing about what current package managers do and don't do. Satisfiability problems of this kind appear in a ridiculous number of fields and applications (and not just by reduction). The vast majority of them, in practice, are approximated rather than exactly solved. Most of the ones that are exactly solved are in software verification, model checkin…

> The idea that "package management" is one of those areas that absolutely must be exactly solved to generate acceptable results seems to me to be ... probably wrong. The logical conclusion of your statement is that minimal version selection is the wrong approach ! Minimal version selection is an "exact" solution, in contrast to the traditional one. You would only arrive at MVS if you considered the problem of select…

You didn't find example of failed Cargo because most of the time it just do like go get -u, and solve a non-problem !

Re: A response about dep and vgo

#115

Post by kaeshiwaza »

pa7ch wrote: post #31
cweagans wrote: post #14

Earlier quoted context omitted.

Throwing away dep means also throwing away the nontechnical groundwork that dep was built on - for instance, user research. Seems pretty careless to me, especially when the alternative is the product of one person's thinking on the subject done in a vacuum without the input of an entire committee of smart, reasonable people who have literally spent years diving into this specific domain.

As a user of dep, glide, godep and avid reader of vgo technical docs I favor vgo's solution. I've been a professional Go developer a few years now. The notion that this committee speaks for the community seems a weak one to me and I've seen my view mirrored with many of my peers. Its good they attempted such research but it seems like confirmation bias as dep just seemed like a re-write of glide with similar fundamen…

I have exactly the same feeling. And remember at the time of the start of Dep that there was no consensus and a big hope that the final integrated solution will be more Goish than Glide. Very surprised by the begin of Dep. I don't believe that rsc and the go team didn't know since the begin that it will not fit sooner or later...

Re: A response about dep and vgo

#116

Post by kaeshiwaza »

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…

The implementation of vgo (so simple) cannot be compared to dep. It can explain why it was more easy to just do it than spend time to explain. It's often like that in dev, when we find a simpler solution in our own code we just do it and throw away the old complicated one.

Re: A response about dep and vgo

#117

Post by cdoxsey »

coldtea wrote: post #21

> Community consensus is not always possible. If we don’t get there, then the core Go team decides. Technically I am the final decider but what actually happens is that a bunch of long-time Go team members talk through the decision to get to a consensus among ourselves. Was anything major ever decided based on a "community consensus" in Go? What I've read about, and this case is no exception, is that it's always "a b…

Its more open than the OS example. There have been community discussions on many issues related to the language. The core team solicits feedback, and designs are often adjusted in light of that feedback. Consider type aliases:

https://github.com/golang/go/issues/18130

Its also an example of the proposal process which is PEP like.

That said, changes like this are not decided by the community, but by the core team. Go is an opinionated language and far more ideas have been rejected than accepted. For example Ian Lance Taylor's 5 generics proposals: https://github.com/golang/proposal/blob/master/design/15292-....

Re: A response about dep and vgo

#118

Post by coldtea »

geodel wrote: post #62
coldtea wrote: post #43

Earlier quoted context omitted.

Not sure about the swift-server-group situation -- some where blindsided, but here's e.g. the head of the closely related Vapor (server side web framework) project: "I've seen a surprising amount of people thinking that the server-side Swift community or the Swift Server working group was somehow blind-sided by SwiftNIO. That couldn't be farther from the truth. We had known about SwiftNIO before the first line of Vap…

Well discussion is all fine. The important thing will be if Swift core team which is all Apple employees (except Chris Lattner who left Apple recently and removing him would look petty) will simply accept community solution even if they don't think its right. I don't know of examples if anything got in Swift just by force of community without core team approval. And it seems right thing to me whether Swift or Go or R…

>I don't know of examples if anything got in Swift just by force of community without core team approval.

It's not about that though. Of course the core team should approve. It's when the core team only approves its own things, which often are designed decidedly not the way that the community wants, that's the problem.

Re: A response about dep and vgo

#120

Post by weberc2 »

geodel wrote: post #59
munificent wrote: post #19

Earlier quoted context omitted.

> 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. No, that doesn't work in practice. The network effects are so insanely dominant in open source projects that forks are nowhere near an efficient market.

Libreoffice vs Openoffice, Hudson vs Jenkins, and there would be so many more.

Like the OP mentions in another comment, this is survivorship bias.
Post reply on HN