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

Go += Package Versioning

research.swtch.com

Post reply on HN
Print view View original

171–180 of 213 posts

Re: Go += Package Versioning

#171

Post by peterevans »

pmarreck wrote: post #168
munificent wrote: post #33

I'm going to comment mostly on the parts of the proposal that I think are wrong, but don't take this to be an overall negative response. I'm excited to see smart folks working on this, and package management is a really hard problem. There are no silver bullets to code reuse. Context for those who don't know: I along with Natalie Weizenbaum wrote pub[1], the package manager used for Dart. > Instead of concluding from…

How would it be possible to guarantee reproducible/deterministic compatibility without using something like the hash of the entire library as an implicit "version"? (say, the git SHA) I believe that the Nix OS does something along these lines to guarantee deterministic builds. A number of times in at least a couple of languages, I've seen a library keep the same (exact) version number but make some small "bugfix" cha…

The proposal doesn't seek to guarantee reproducible builds; it merely seeks to enable them, through the methods they outline.

If you did want to guarantee reproducible builds with SHA-1 hashes, one way would be to introduce those into the .mod files they outlined. But that'd be clunky; it's much easier to reason about a version number than it is a digest hash.

Another method would be to introduce a lock file where those details are kept from plain view, but my sense was that they wanted a little more openness about the mechanism they were using than a lockfile provides (which is why .mod files use Go syntax, save the new "module" keyword they would introduce). After all, that's how dep works right now: they might as well just keep the lock file.

Cases where tags are being deleted, or worse—where accounts are deleted, then recreated with (other? same?) code, may be said to break the semver contract the library or binary author someone has with their users. As such, it may be seen as outside of scope for what they are seeking to accomplish with vgo.

Re: Go += Package Versioning

#172

Post by pjmlp »

jdoliner wrote: post #53
thrownaway954 wrote: post #50

Earlier quoted context omitted.

personally this is the main reason I have avoided go from the beginning. without being able to specify a version of the library I want to use, whose to say that the next time I try to run my program it might use a newer version of a library and not run. If that happens there was no easy way around it other than digging into the code and fixing the problem.

Since Go is compiled and statically linked there's no way that library version can change between runs of your program. It can change between compilations of your program though, the standard go solution to that is vendoring code which will guarantee that it's always the same code getting compiled. This is not without its issues, but I find it to be a pretty usable system, just smart enough to get what I need done. T…

Go stopped being statically linked a couple of versions ago.

Yes, by default it uses statically linking, however generating dynamically linked binaries and libraries is also an option.

Re: Go += Package Versioning

#173

Post by pjmlp »

merb wrote: post #100
hota_mazi wrote: post #95

Earlier quoted context omitted.

Or adopt a system with a sane versioning system and immutable artifacts, e.g. Maven Central.

which still means that your ci needs to download this stuff. with vendor it is already checked it. consider builds on docker etc, where build caching is hard. go is a breeze. build takes like half a second because everything is already there. mvn will first download the world. I'm a scala developer and sbt will probably take like 10 minutes just downloading stuff, if a cache missed (even with a local proxy).

I wonder how it is possible to take 10 minutes, unless it is downloading directly from internet.

We always have internal Plexus mirrors, and the Jenkins servers have their global .m2 local repository.

Even big JEE applications barely take more than 5 minutes to build.

The only build system I really dislike are Android builds with Gradle, trying to beat C++ compilation times.

Re: Go += Package Versioning

#174

Post by LaGrange »

hota_mazi wrote: post #95
LaGrange wrote: post #86

Earlier quoted context omitted.

Yeah, this. You want reproducible builds? Vendor your crap. Check it into your repository. Live free.

Or adopt a system with a sane versioning system and immutable artifacts, e.g. Maven Central.

First things first, Maven's config files are an elaborate form of torture. Second, there is no such thing as remote artifacts that are immutable.

Check your shit into your git repository. And managing that becomes a problem, you've already done goofed up and have too many dependencies, and it's unlikely there's _anything_ reproducible about your software.

Re: Go += Package Versioning

#175

Post by merb »

pjmlp wrote: post #173
merb wrote: post #100

Earlier quoted context omitted.

which still means that your ci needs to download this stuff. with vendor it is already checked it. consider builds on docker etc, where build caching is hard. go is a breeze. build takes like half a second because everything is already there. mvn will first download the world. I'm a scala developer and sbt will probably take like 10 minutes just downloading stuff, if a cache missed (even with a local proxy).

I wonder how it is possible to take 10 minutes, unless it is downloading directly from internet. We always have internal Plexus mirrors, and the Jenkins servers have their global .m2 local repository. Even big JEE applications barely take more than 5 minutes to build. The only build system I really dislike are Android builds with Gradle, trying to beat C++ compilation times.

well sbt uses ivy which is way slower than maven, when it comes to resolving stuff.

Re: Go += Package Versioning

#176

Post by lloeki »

jadeklerk wrote: post #7
Sir_Cmpwn wrote: post #5

>End of GOPATH Yes yes yes yes finally! This has been the #1 reason I've avoided Go for years and even my recent forays back into the language were only after I figured out some hacks that I could use to avoid it.

Because you didn't want to set an env var?

The problem is not the env var, because whether or not it was set or with a default value, you have to clone the project https://github.com/foo/bar.git at ~/go/src/github.com/foo/bar and name the imports github.com/foo/bar accordingly and run the go commands from there. I used to (automatically) just export GOPATH="${PWD}/.gopath" but this doesn't work anymore since 1.8 or 1.9.

People† at large just want to clone https://github.com/foo/bar.git wherever they see fit, like directly at ~/Workspace/bar, ~/work/bar, ~/projects/contrib/bar or even /tmp/bar.

† "People" includes CI systems that expect the typical "clone and cd straight into" thing to work, resulting in a lot of boilerplate and/or symlink hacks to work around such expectations.

Re: Go += Package Versioning

#177

Post by ithkuil »

munificent wrote: post #132
joncalhoun wrote: post #114

Earlier quoted context omitted.

You (and likely everyone else) should look at the tour as well before commenting, as I think many people are misunderstanding some of the subtler points. > If I'm starting a brand new from scratch Ruby on Rails application today, in 2017, there is no reason it should default to having me use Rails 1.0 from 2005. In the tour it states, "We've seen that when a new module must be added to a build to resolve a new import…

> In the tour it states, "We've seen that when a new module must be added to a build to resolve a new import, vgo takes the latest one." which means that the newest Rails would be used and set in your `go.mod` file. That works for adding a new dependency. But, as I understand it, if I decide to upgrade my dependency on foo by changing its already-present version in my app's module file, this does not upgrade any of t…

The new release of the dependency can also bump the minimum required versions of its dependencies, as part of their release cycle. If they don't, you can upgrade them as any other dependency; after all transitive dependencies are just dependencies.

That said, you can just upgrade all the dependencies with vgo get -u and get the "always latest" behaviour. This is a desirable result, but it shouldn't happen at each and every fresh build.

You can have automation that periodically tries to bump all the versions and if all tests passes send you a PR with the proposed update.

With the proposed rules you get 1. Repeatable builds as with lock files 2. Simple to reason about constraint resolution on case of multiple modules depending on the same module.

Re: Go += Package Versioning

#178

Post by neoasterisk »

Groxx wrote: post #164
Sir_Cmpwn wrote: post #12

Earlier quoted context omitted.

I should add that another big part of the reason I've been avoiding the language for years is the cult of Golang telling me my complaints are "totally naive and irrational".

This kind of attitude around package management and especially dependency injection have been major turn-offs for me as well. More than a sufficient number of the community has been emitting a high-pressure stream of NIH combined with ignorance of existing solutions, and it has been crippling the community for years.

Dependency injection is very commonly used in the Go ecosystem. Do not confuse resistance about unidiomatic DI frameworks with resistance about DI itself.

Re: Go += Package Versioning

#179

Post by ithkuil »

XorNot wrote: post #130
dkarl wrote: post #124

Earlier quoted context omitted.

For what it's worth, Dart does not let you have two versions of the same package in your application, even different major versions. This restriction does cause real pain, but it doesn't appear to be insurmountable. Most of the pain seems to be in the performance issues over-constrained dependencies caused in our old version solver and not in the user's code itself. In almost all cases, I think there is a single vers…

I'm not really enthused by efforts to bring in the same packaging constructs as other languages, which all have the effect of making time-to-compile after git clone longer. Frankly I think we tend to conflate two separate but related tasks in these discussions: communicating updates, and distributing dependencies. vendor/ folders are a totally fine distribution system - optimal even. Time-to-compile is 0 because you…

Yeah, I'm also a bit concerned with vendoring going away. The proposed solution to preserving upstream is imho very elegant (caching proxies) and scales better than vendoring, but it requires a bit more infrastructure. Perhaps vgo could be taught to look in a local directory for an exploded content of what logically is the upstream archive (and that local directory could be checked in git, or preserved as a cache by your CI etc).

Re: Go += Package Versioning

#180

Post by h1d »

stickfigure wrote: post #58
Animats wrote: post #23

I have misgivings about all this version pinning. At first, it seems to make things easier. Programs don't break because some imported package changed. So it looks like a win. At first. Over time, though, version pinning builds up technical debt. You have software locked to old unmaintained versions of packages. If you later try to bring some package up to date, it can break the fragile lace of dependencies locked in…

This is horrible advice. I work in a lot of languages (including Go), which gives me some perspective. On the extreme ends of this issue we have Maven, which specifies hard version numbers (fuzzing is possible but culturally taboo) and NPM, which only recently acquired the ability to lock version numbers and still has a strong culture of "always grab latest". The Maven approach is unquestionably superior; code always…

> I waste stupid amounts of time fighting with upstream dependencies rather than delivering business value.

Have you paid the upstream developers? Because you sound like you did.

Post reply on HN