4 ms·
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/
by krat0sprakhar 11y ago
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
- ayanamist 11y agoThis 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.
- nulltype 11y agoWell one official solution would be to use the vendor path.
- jeremyjh 11y agoThis 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.
- serge2k 11y ago> I know go's package management is pretty simple fixed. I like cargo's system for this.
- deleted 11y ago[deleted]
- danieldk 11y agoThis 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 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/ http://gopkg.in/ that allow you to expose version branches as a different import paths.)
- lobster_johnson 11y agoThis 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 https://gopkg.in
- deleted 11y ago[deleted]
- icebraining 11y agoUnless 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.
- m_sahaf 11y agoI 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/...