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

51–60 of 139 posts

Re: A response about dep and vgo

#51

Post by Athas »

kenhwang wrote: post #47
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…

I'm still mind-boggled by the crusade against the lockfile. It's a completely unambiguous source for everything that costs essentially nothing, why is there so much time and energy devoted to getting rid of it? Especially with all the drawbacks minimal version selection comes with; exact version selection with the lockfile seems better in just about every case.

I don't think the lockfile is a big problem (and I don't have enough experience with lockfile-based systems), but if you already have some other file that can serve the same purpose, isn't that nicer than having two? It also means you don't have to be confused about whether lockfiles should be committed to version control (apparently the answer is "not always", which is counter-intuitive to me).

Re: A response about dep and vgo

#52

Post by jasonwatkinspdx »

claydavisss wrote: post #3

Go does not exist to raise the profiles of Sam Boyer and Peter Bourgon. Sam wanted to be a Big Man On Campus in the Go community and had to learn the hard way what the D in BDFL means. The state of dep is the same as it was before - an optional tool you might use or might not. Lots of mentions in Peter's post about things the "dep committee" may or may not have agreed with. Isn't this the same appeal to authority he…

This is some pretty ugly character assassination. I haven't seen anything that justifies your characterizations of Sam or Peter.

Re: A response about dep and vgo

#53

Post by jessaustin »

Athas wrote: post #49
jessaustin wrote: post #46

Earlier quoted context omitted.

Minimal Version Selection. That's really interesting. Obviously this would lead to fewer regressions, but it seems opposed to the "security problems fixed for free" scenario you hear about with other package dependency schemes. Were we all just imagining that scenario? Is there another way we should be handling vulnerabilities, i.e. by "repudiating" old versions rather than simply releasing new ones? Then you could h…

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.

What you're saying makes perfect sense. This is what makes HN great. Incidentally, there's nothing about e.g. npm that would prevent this scheme: just set literal version numbers instead of using operators. The two systems definitely have different "best practices".

Re: A response about dep and vgo

#54

Post by sagichmal »

claydavisss wrote: post #35
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…

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.

Re: A response about dep and vgo

#55

Post by stcredzero »

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.

I couldn't tell if that assertion was ironic or not.

Re: A response about dep and vgo

#56

Post by ansible »

nicpottier wrote: post #40
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.

Open Source is absolutely chock full of examples of this.

And sometimes the new community wins out over the existing one. LibreOffice vs. OpenOffice, X.org vs. XFree86, etc.

Re: A response about dep and vgo

#57

Post by infogulch »

Athas wrote: post #38
pas wrote: post #33

Earlier quoted context omitted.

Could you contrast Cargo and vgo for those who only know the former?

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…

Adding to this:

> vgo tries to install the oldest version of a packages that still satisfies any lower bounds specified anywhere in the dependency tree

Another benefit of this that may be a little less obvious (it wasn't obvious to me) is that this means every package-version selected by MVS in the entire dependency tree is explicitly specified somewhere in the dependency tree. This means that every selected package-version was specifically tested with at least one other package (assuming, reasonably, that libraries are tested with the versions that they specify). You don't get this with SAT, in fact it's possible for SAT to select a set of packages where no two package-versions were ever tested with each other anywhere else before.

I feel that this property, combined with upgrades requiring affirmative action by the root package maintainer (by editing go.mod or having a tool do it), will make vgo-managed packages much more reliable over time.

Re: A response about dep and vgo

#58

Post by necubi »

Athas wrote: post #49
jessaustin wrote: post #46

Earlier quoted context omitted.

Minimal Version Selection. That's really interesting. Obviously this would lead to fewer regressions, but it seems opposed to the "security problems fixed for free" scenario you hear about with other package dependency schemes. Were we all just imagining that scenario? Is there another way we should be handling vulnerabilities, i.e. by "repudiating" old versions rather than simply releasing new ones? Then you could h…

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.

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.

Re: A response about dep and vgo

#59

Post by geodel »

munificent wrote: post #19
nicpottier wrote: post #13

Earlier quoted context omitted.

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…

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

Re: A response about dep and vgo

#60

Post by vorg »

munificent wrote: post #22
yawboakye wrote: post #16

Earlier quoted context omitted.

> This is the same reason given for totalitarian rule generally. The problem is that the dictator has enough power to make a big mistake, committing the entire communitiy's resources. In this position, if you can avoid making a decision, you should. Toyota doesn't simply make such decisions by fiat. Instead, they have a competition. You're comparing very different things. Programming languages and empires/nations/com…

> Rails has stayed on the course DHH wants it and hasn't become a mess mainly because DHH remains the BDFL. \* and DHH happens to make good decisions frequently enough. For every successful BDFL example, history is littered with a hundred dead languages and frameworks designed by a single visionary leader who made the wrong decisions.

> a hundred dead languages and frameworks designed by a single visionary leader who made the wrong decisions

E.g. there's the namesakes for Rails and Ruby, i.e. Grails and Groovy. Virtually no-one's upgraded to Grails version 3 since it came out 3 yrs ago, or started new projects in Grails version 2. The Grails 2 plugin ecosystem is as good as dead. It only has its "single visionary leader" listed for the 3 contact persons (owner, admin, tech) in the grails.org DNS registration.

As for Apache Groovy, it's hanging on as the build language for Gradle and Android Studio, but doesn't seem to have any other significant use besides its original use case of glue code and testing harnesses. Groovy's problem is its creator, who had successfully added closure functionality to a clone of Beanshell, left the project after 3 yrs and the "despot" at Codehaus who subsequently claimed the title Project Manager was someone who didn't have the aptitude for many programming tasks.

Post reply on HN