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

131–139 of 139 posts

Re: A response about dep and vgo

#131

Post by reggieband »

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…

That may work for my dependencies but not the dependencies of my dependencies. In other words, for that to work it isn't enough for me to change - every npm library maintainer must change.

Re: A response about dep and vgo

#132

Post by agnivade »

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…

Yep, this is it. Russ himself admits it. He was corresponding with Sam about his ideas and thought that would be sufficient. Whereas, he should have done that with the entire community and been more explicit about where he was going.

Re: A response about dep and vgo

#133

Post by agnivade »

c2h5oh wrote: post #8
tptacek wrote: post #5

Earlier quoted context omitted.

I don't see the comparison you're drawing here. The question proposed in the Go issue is whether the standard bignum library in Go should be constant-time, whether crypto primitives should provide their own constant-time math, or whether a third library for constant-time bignum math should be added that all Go crypto can rely on. That's not an easy question, and meanwhile significant chunks of the bignum crypto code…

> I don't see the comparison you're drawing here. I think the similarity is as follows: - there is a desire to fix something that feels like a gap (in this case limited support of constant-time math in standard library) - there is a change proposal coming from the community - there are arguments why it should be included and some discussion if it belongs in a separate library or not - very little or no input from cor…

I think your expectations from huge open source projects are a bit too much. There are over 3500 issues open currently as of this moment, and new issues get opened every 15-20 minutes. The Go core team is like 10 people. That being said -

> - very little or no input from core team

I simply don't see this being true. Apart from OP (who is expected to comment a lot, because it is his proposal), the thread has comments from Robert Griesemer, Russ Cox, Austin Clements, Adam Langley and many others.

> - the whole process is stalled waiting for core team to participate

Again, not true. See Ian's and Russ' last comment. It is actually waiting on further information.

All that being said, instead of complaining how there is no response on a thread by the core team, maybe you can contribute by answering the questions Russ and Ian has raised, and ping others as needed.

Re: A response about dep and vgo

#134

Post by pcwalton »

kaeshiwaza wrote: post #130
pcwalton wrote: post #128

Earlier quoted context omitted.

> Certainly you realize the complexity and other differences between "an exact solver for SAT" and "an approximation of a SAT problem as a 2-SAT problem + an exact solver for 2-SAT" I'm saying that the theoretical complexity of the core dependency resolution algorithm is irrelevant in practice. Therefore, removing useful features to reduce SAT to 2-SAT is not a good trade. I, and everyone else who has worked with Car…

In large software you'll not do go get -u for all packages, you'll upgrade each package separately, at the maximum version or at a specified one. It's just that it's you the user of the modules will choose what and when you upgrade, not the(this) tools automagicaly.

> It's just that it's you the user of the modules will choose what and when you upgrade, not the(this) tools automagicaly.

You've correctly identified the problem with vgo.

Re: A response about dep and vgo

#136

Post by jessaustin »

pcwalton wrote: post #129
jessaustin wrote: post #127

Earlier quoted context omitted.

This is the whole point: just specify the version before the change, and it won't bother you.

Until someone actually wants to update their dependencies, writes "go get -u", and breaks the build.

Well sure, you probably want to test after updating all of those dependencies. That's a good reason to only update when necessary. Do you argue that some other scheme prevents bugs in dependencies? That hasn't been my experience...

Re: A response about dep and vgo

#137

Post by eritain »

lizmat wrote: post #45
claydavisss wrote: post #37

Earlier quoted context omitted.

The only meaningful example of this I can think of is Larry Wall and Perl...but his mistake was in loosening his grip instead of tightening it. Perl6 started off as a utopia wherein Larry was only considered slightly more powerful than any other contributor. This resulted in a revolving door of clowns taking the reigns and rapidly resigning as Larry looked on. Fortunately Perl5 still does the Pumpking thing which is…

> This resulted in a revolving door of clowns taking the reigns and rapidly resigning as Larry looked on. I would say that this hasn't been the case for the past 10 years at least. Patrick Michaud has been Perl 6 pumpking since then, to make room for Jonathan Worthington about 2 years ago. Hardly a revolving door and hardly clowns.

Parrot did burn through quite a few pumpkings. I wouldn't call them clowns either, but I do think they led Parrot astray. Obviously Parrot is not Perl 6, but they are closely linked in many people's minds for obvious reasons.

(It's not all the pumpkings' fault, either. I think Parrot would still have been doomed if its leadership were constantly flawless, just because it was designed before Perl 6's object system was.)

Re: A response about dep and vgo

#138

Post by Merovius »

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…

> Minimal Version Selection. In contrast to pretty much every other package manager, vgo tries to install the oldest version of a packages that still satisfies any lower bounds specified anywhere in the dependency tree.

This is somewhat misleading. Most package managers use a human-edited manifest containing constraints and a machine-edited lockfile, containing the chosen versions. You periodically (or after changing dependencies to require newer versions) run a tool that fetches the newest versions satisfying your constraints and writes out a lock-file, which you then commit and use at install-time to get reproducibility.

Go modules use a single file that serves as both and is both human- and machine-edited. You periodically (or after changing dependencies to require newer versions) run a tool that fetches the newest versions satisfying your constraints and updates the manifest with them. The manifest is then (also) used at install-time with minimum version selection to get reproducibility.

What that means is that in practice, Go modules never install older versions than the equivalent in other package managers would do. The maintainer specifies constraints and uses a tool to decide what version will actually used to at build-time. In both cases, that tool will choose the newest versions available.

What is correct (and contentious) is that Go modules have no concept of upper bounds for dependencies. So the complaint is, that as a library author you can not prevent a newer version from being chosen by one of your reverse dependencies. It remains to be seen how much of a problem that will be in practice.

So, if anything, the problem is that as opposed to other package managers, Go modules sometimes choose too new versions, from the perspective of some people. It never chooses too old versions.

Re: A response about dep and vgo

#139

Post by [deleted] »

lilyball wrote: post #73
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…

> but also gives you reproducible builds without using a lockfile (which is nice) I find the claims that vgo removes the lockfile disingenuous. Yes it's technically correct in that there's no lockfile, but it's incorrect in that you've basically turned the file that declares dependencies into the equivalent of a lockfile. With something like cargo, I can `cargo update` and it will fetch new versions of my dependencie…

[deleted]
Post reply on HN