4 ms·
Go get is an astonishing demonstration of failing to learn the lessons of the past; it's bad enough watching Python, Ruby, Node, Java et. al. painfully re-inven
by ldite 11y ago
Go get is an astonishing demonstration of failing to learn the lessons of the past; it's bad enough watching Python, Ruby, Node, Java et. al. painfully re-invent the wheel of dependency management, but at least they seem to have gained the notion of versioning.
Go seems to have taken a look at the carnage of decades of dependency hell and decided "if we make no effort to provide a system then people will be forced to produce sane stable APIs".
I've picked the short straw of trying to reproducibly build and package Go based projects for internal projects. The combination of go get and the Go ecosystem's cultural lack of versioning and stability are giving me a deep dislike of the language.
First you have to play git-bisect on the dependencies (after you've hunted them down because of repo renames) in order to find the most recent one it builds against (and who knows if that was the one written against!) Then you have to futz around to add in either some custom or third party vendoring script, and then you have to rinse and repeat for second order dependencies.
For example, take the author's own first linked project. Following the build instructions:
~ $ mkdir ~/syslog-gollector
~ $ cd ~/syslog-gollector
~/syslog-gollector $ export GOPATH=$PWD
~/syslog-gollector $ go get github.com/otoolep/syslog-gollector
package github.com/otoolep/syslog-gollector
imports code.google.com/p/log4go
imports github.com/otoolep/sarama
imports code.google.com/p/snappy-go/snappy: unable to detect version control system for code.google.com/ path
~/syslog-gollector $ go install github.com/otoolep/syslog-gollector
src/github.com/otoolep/sarama/snappy.go:5:2: cannot find package "code.google.com/p/snappy-go/snappy" in any of:
/usr/lib/golang/src/code.google.com/p/snappy-go/snappy (from $GOROOT)
/home/ldite/syslog-gollector/src/code.google.com/p/snappy-go/snappy (from $GOPATH)
Well, I'm shocked.
- hellbanner 11y agoI gave up Go from Google's tutorial level 1 when I had a compile error. What language ecosystems do you feel have good dependency management?
- alexro 11y ago.net is good to me
- escherize 11y agoAnecodtal, but over 2 years I've never had a problem with Clojure's dependency management.
- koloron 11y agoHaskell has a pretty cool new dependency management tool called stack (https://github.com/commercialhaskell/stack https://github.com/commercialhaskell/stack). It's based on the curated package server https://stackage.org https://stackage.org which server sets of packages that are tested for compatibility.
- e-dard 11y agoMaybe that's just poor documentation on the author's part. If you simply try and go get the package (running Go 1.5 here): ~ $ go get -u github.com/otoolep/syslog-gollector warning: code.google.com is shutting down; import path code.google.com/p/log4go will stop working warning: code.google.com is shutting down; import path code.google.com/p/snappy-go/snappy will stop working ~ $ Everything is fine (aside from the warnings about code.google shutting down). Yes, Go does not have a culture of versioning, but it _does_ have a culture of _vendoring_. You should be getting your reproducible builds by vendoring your dependencies. That way, you don't need to do any hunting or git-bisect shenanigans.
- kasey_junk 11y agoExcept in your example your command will update the vendored code, potentially (and in some cases probably) breaking dependencies. It is a fact, that the go dependency management story is weaker than nearly any of the other modern development environments there are. It is getting better through time, and probably won't a problem long term (and for many people isn't a problem now). But lets not act like it isn't a weakness.
- ldite 11y ago> You should be getting your reproducible builds by vendoring your dependencies. As I said, I've been working with code I didn't write: I've effectively been taking other people's *hub code and vendoring it for them, because they haven't. This is not optimal. And this isn't trivial projects, either, e.g. https://github.com/influxdb/influxdb/ https://github.com/influxdb/influxdb/ (also connected to the author!) still uses trivial go get, and doesn't make any effort to help with vendoring.
- timtadh 11y agoI cannot upvote this enough. Go's dependency management is horrible. The fact that I have to encode my current github account to make things `go get`able is crazy! When projects move accounts or hosts it breaks everything. Not to mention that no one doing Go seriously actually uses `go get` to download dependencies. But, if you want the broadest audience for a library it needs to support `go get`! There is furthermore, no way to build release packages that people can just install. There are no tarballs or jars or anything else that can be simply downloaded and depended on. So not only is everything tied to my github account I can't even release stable versions in any sane way. I never thought I would say "Man Java is really doing it right" but in comparison to Go it is! I love writing in the language, but I solve this problem by mostly depending on only stuff I have written. That way I can at least control the problem. I have even started using submodules again! At least that way I can pin my dependencies to specific versions without having to use a third party tool. Insanity!
- clessg 11y agoYeah. Lately there's been a lot of people recommending that you just copy and paste code. Dependency management for the future.
- seiji 11y agoYou can't fight a cargo cult because they are proud of their irrational beliefs—they tie their backwards rituals into their private self image. You can't out rationalize them because you aren't fighting their tools—you are fighting their perception of themselves. That's a thing people will die for. The only way out is to get them focusing on a new cult instead, thereby changing their self-ego attachment to less broken and less dangerous ideas. edit: lol downvotes