Hacker News Reader

Comment by krat0sprakhar | Hacker News Reader

OT: I'm a Go noob and I was wondering if there's something like requirements.txt for Go projects? Or is this usually the way to go?

    go get -u golang.org/x/crypto/ssh
    go get -u github.com/dlintw/goconf
    go get -u github.com/golang/glog
    go get -u github.com/golang/protobuf/{proto,protoc-gen-go}
    go get -u github.com/miekg/dns

View on HN

This looks incredibly brittle. What if one of those dependencies releases a new major version on its master branch that breaks compatibility? It was really surprising to see this done this way. I know go's package management is pretty weak but a serious project like needs reproducible builds. Since all the dependencies are on git they could just use git submodules in a vendor directory or something.

> I know go's package management is pretty simple

fixed.

I like cargo's system for this.

This looks incredibly brittle. What if one of those dependencies releases a new major version on its master branch that breaks compatibility?

You are not supposed to do this in Go. If you make changes that are API-incompatible, you need to create a new import path. From the Go FAQ:

Packages intended for public use should try to maintain backwards compatibility as they evolve. The Go 1 compatibility guidelines are a good reference here: don't remove exported names, encourage tagged composite literals, and so on. If different functionality is required, add a new name instead of changing an old one. If a complete break is required, create a new package with a new import path.

https://golang.org/doc/faq#get_version

Whether this is a good approach is the question, but pushing API compatibilities to an existing import path is considered to be bad.

(Since creating a new repository for each API-breaking version is annoying, there are sites such as http://gopkg.in/ that allow you to expose version branches as a different import paths.)

This is (sadly) why gopkg.in [1] exists. It proxies Git repositories, mapping:

  gopkg.in/mypackage.v3     -> github.com/go-mypackage/mypackage

  gopkg.in/bob/mypackage.v3 -> github.com/bob/mypackage

...where v3 is a branch or tag named v3, v3.N or v3.N.M.

What Go needs is a real package manager that uses the new 1.5 vendor directory to manage dependencies. There have been some attempts (godep, gb), but they aren't very good, especially if you look at how existing languages have solved this (Ruby's Bundler, Rust's Cargo).

[1] https://gopkg.in

This is the biggest problem in golang ecosystem. Yes there are many third party solution, but no official one. So different repo use different solution make all solutions invalid.

Well one official solution would be to use the vendor path.

Unless there's something weird about that repo, go usually figures out what it needs to pull from the imports, you don't need to manually specify them.

Doing "go install github.com/google/seesaw" should do everything for you.

I don't know why they used that in the README, but "go get" has this approach to fetch dependencies like that:

go get -u github.com/google/seesaw/...

Reply on news.ycombinator.com