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

121–130 of 139 posts

Re: A response about dep and vgo

#121

Post by weberc2 »

geodel wrote: post #79
zellyn wrote: post #7

Earlier quoted context omitted.

I've interacted quite a bit with both Sam and Peter. Your characterization rings completely false. I've never gotten the least hint of the impression they were doing this for self-promotion, but rather to serve to fill an obvious vacuum, perhaps even with a degree of reluctance. I remember being excited when the “dep committee” was formed, because (if I remember correctly) it was set up with the explicit blessing of…

> Your characterizations are both inaccurate and ugly. I think it may be blunt but seems true to me. Sam calling integration of Go module as sad milestone does seem disgruntled. Dep folks have decided not to take high road which is fine but others are free to call this out.

I want vgo to succeed and I like most of your contributions, but comments like this and the original post (“Sam just wants to be the big man on campus”) are petty and rude. You’re better than this.

Re: A response about dep and vgo

#122

Post by geodel »

weberc2 wrote: post #121
geodel wrote: post #79

Earlier quoted context omitted.

> Your characterizations are both inaccurate and ugly. I think it may be blunt but seems true to me. Sam calling integration of Go module as sad milestone does seem disgruntled. Dep folks have decided not to take high road which is fine but others are free to call this out.

I want vgo to succeed and I like most of your contributions, but comments like this and the original post (“Sam just wants to be the big man on campus”) are petty and rude. You’re better than this.

Not that I disagree with you. But this unending whining by dep folks is not helping them endeared to me or so many others.

Re: A response about dep and vgo

#123

Post by geodel »

samat wrote: post #109

I don’t have extensive knowledge of the matter in hand, but this narrative seems much more coherent. And sad for Go/Google. So much for “open”. Just like Android/Google play services thing. Calling something “open” a hundred times a day does not remove one bit of corporate control.

If someone is putting >90% of funding for project, it is just common sense they will veto things they do not like. I wonder if some people believe that online cliche about open source is all there to it.

Re: A response about dep and vgo

#124

Post by pcwalton »

kaeshiwaza wrote: post #112
pcwalton wrote: post #108

Earlier quoted context omitted.

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

Except for version 0.x, and with vgo you have no recourse if somebody didn't follow the rules and made an incompatible change.

Re: A response about dep and vgo

#125

Post by DannyBee »

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…

I feel like you are really stretching here. You took a bunch of words out of context so you could parse them.

"Minimal version selection is an "exact" solution, in contrast to the traditional one. "

It's not an exact solution to SAT, it's an exact solution to a simpler problem than SAT (2-SAT). A problem that admits linear time solutions, even.

That is in fact, what a lot of approximations actually are - reduction of the problem to a simpler problem + exact solving of the simpler problem.

Some are heuristic non-optimal solvers of course, but some are not.

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 can write a linear time 2-SAT solver in about 100 lines of code and prove it's correctness. It's even a nice, standard, strongly connected component based solver.

Here's a random one: https://github.com/kartikkukreja/blog-codes/blob/master/src/...

So if i have an SCC finder implemented somewhere, it's like 20 lines of code.

Past this, your argument about "taking the user's time" is so general you could apply it to literally any problem in any domain. You can just plug in whatever domain you like and whatever solution you happen to like into this argument.

Here it's backed by no data - you have surfaced zero evidence of your premise - "that it is taking user time". This entire thread in fact has exactly no evidence that it's taking any appreciable amount of user time, so it definitely fails as an argument.

(in fact, the only evidence presented in this thread is that the algorithm simply works on existing packages)

If you actually have such evidence, great, i'm 100% sure that go folks would love to see it!

Because right now the main time spend, in fact, seems to be people arguing in threads like these.

Re: A response about dep and vgo

#126

Post by e12e »

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 had some experience with plone (and zope) - big, early python projects that formed a lot of the basis for package management and infrastructure for python.

The "known good set" of packages as used by buildout for any given plone version were not really easy to work with.

See eg:

https://docs.plone.org/4/en/manage/troubleshooting/buildout....

Which points to things like: http://dist.plone.org/release/3.3.5/versions.cfg

Which aren't that much worse/better than a gemfile.lock for a rails project, I guess.

Now, I guess the better answer is to have smaller projects, with different interfaces (eg: don't give all modulles/parts access to your zodb object database, have a ome json/rest interfaces etc).

But apparently there are still many "big systems" being built.

Re: A response about dep and vgo

#127

Post by jessaustin »

pcwalton wrote: post #124
kaeshiwaza wrote: post #112

Earlier quoted context omitted.

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

Except for version 0.x, and with vgo you have no recourse if somebody didn't follow the rules and made an incompatible change.

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

Re: A response about dep and vgo

#128

Post by pcwalton »

DannyBee wrote: post #125
pcwalton wrote: post #107

Earlier quoted context omitted.

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

I feel like you are really stretching here. You took a bunch of words out of context so you could parse them. "Minimal version selection is an "exact" solution, in contrast to the traditional one. " It's not an exact solution to SAT, it's an exact solution to a simpler problem than SAT (2-SAT). A problem that admits linear time solutions, even. That is in fact, what a lot of approximations actually are - reduction of…

> 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 Cargo, keep saying this, but nobody listens. :(

> Here it's backed by no data - you have surfaced zero evidence of your premise - "that it is taking user time". This entire thread in fact has exactly no evidence that it's taking any appreciable amount of user time, so it definitely fails as an argument.

Minimum version selection makes it the user's problem to fetch the newest version of dependencies. That is the entire premise of minimum version selection. If you want to upgrade your versions, you have to use "go get -u". That command blindly updates all minor versions of packages. The problem arises when you have some packages that did not follow the semver rules (or are on 0.x) and you need to hold them back to avoid breaking your build. That is when the more fine-grained version control that systems like Cargo support becomes essential. Vgo has unfortunately decided to omit that support in favor of some theoretical benefits that make no difference in practice.

> If you actually have such evidence, great, i'm 100% sure that go folks would love to see it!

The Go team has the evidence in that every other package manager uses maximal version selection instead of minimal version selection, because of the problems with minimal version selection.

I strongly suspect that the problems in minimal version selection will become apparent over the years as people hit the limitations, at which point it will become apparent that Go made a mistake, but it will be difficult to fix. In particular, I think that, several years down the line, there's a good chance that running "go get -u" in large software projects is going to result in a broken build, because people are imperfect and don't perfectly follow semver. So people just won't upgrade their packages very often.

Re: A response about dep and vgo

#129

Post by pcwalton »

jessaustin wrote: post #127
pcwalton wrote: post #124

Earlier quoted context omitted.

Except for version 0.x, and with vgo you have no recourse if somebody didn't follow the rules and made an incompatible change.

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.

Re: A response about dep and vgo

#130

Post by kaeshiwaza »

pcwalton wrote: post #128
DannyBee wrote: post #125

Earlier quoted context omitted.

I feel like you are really stretching here. You took a bunch of words out of context so you could parse them. "Minimal version selection is an "exact" solution, in contrast to the traditional one. " It's not an exact solution to SAT, it's an exact solution to a simpler problem than SAT (2-SAT). A problem that admits linear time solutions, even. That is in fact, what a lot of approximations actually are - reduction of…

> 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.
Post reply on HN