Google Open Source Load Balancer in Go

Re:Google Open Source Load Balancer in Go by krat0sprakhar on Saturday January 30, 2016 @07:08PM (#11004475)

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

[ Parent | on HN ]

Re:Google Open Source Load Balancer in Go by jeremyjh on Saturday January 30, 2016 @08:31PM (#11004803)

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.

[ Parent | on HN ]

Re:Google Open Source Load Balancer in Go by danieldk on Sunday January 31, 2016 @07:49AM (#11006235)

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.)

[ Parent | on HN ]

Re:Google Open Source Load Balancer in Go by lobster_johnson on Sunday January 31, 2016 @02:29PM (#11007607)

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

[ Parent | on HN ]

Re:Google Open Source Load Balancer in Go by serge2k on Saturday January 30, 2016 @09:12PM (#11004915)

> I know go's package management is pretty simple

fixed.

I like cargo's system for this.

[ Parent | on HN ]

Re:Google Open Source Load Balancer in Go by ayanamist on Saturday January 30, 2016 @07:10PM (#11004485)

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.

[ Parent | on HN ]

Re:Google Open Source Load Balancer in Go by nulltype on Sunday January 31, 2016 @01:04PM (#11007219)

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

[ Parent | on HN ]

Re:Google Open Source Load Balancer in Go by icebraining on Sunday January 31, 2016 @09:51AM (#11006556)

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.

[ Parent | on HN ]

Re:Google Open Source Load Balancer in Go by m_sahaf on Sunday January 31, 2016 @09:17PM (#11009248)

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/...

[ Parent | on HN ]