[Canonical-tech] Handling active dependencies in Go

James Henstridge james.henstridge at canonical.com
Tue Dec 18 08:02:40 UTC 2012


On Tue, Dec 18, 2012 at 2:42 PM, David Cheney
<david.cheney at canonical.com> wrote:
> I vote for A. While I don't say this publicly, the go get tool is a toy. It's a good start, but we've clearly exceeded its capacity.

If "go get" is a toy, then it would make sense to either (a) encourage
everyone to use something else, or (b) improve the tool so that it can
be used in a non-toy manner.  Having to throw out the common build
tool everyone else uses once you need to deal with things like
repeatable multi-package builds.  And using one tool internally to a
project but telling consumers of the project to use something else
seems a bit off too.

Looking at the documentation for "go get":, it sounds like the tool
has some rudimentary support for checking out specific tags or
branches based on the version of the Go runtime.  Perhaps that could
be extended to allow packages to specify how their dependencies should
be pinned.  Given that the tool is distributed with Go, this isn't
really a short term solution, but perhaps it is worth looking into
anyway?

James.



More information about the Juju-dev mailing list