8 ms·
Maybe 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
by e-dard 11y ago
Maybe 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.