Versioning issues with juju-core and goose

[Tim Penhey]

Hi All,

I hit an interesting problem this morning.  One that I'm not entirely
sure how we should go about addressing.

Firstly, I pulled the latest changes to lp:juju-core into my branch in
the $GOPATH/src/launchpad.net/juju-core location.

I then decided to run the tests... they failed (some build build issues).

I recalled that there was an email on the list a while back mentioning
an updated goose needed.

The first issue I see here is there is no dependency management between
revisions of juju-core and other libraries that it depends on.  It seems
that GO is still very immature as a language in this area, and something
that should really be addressed by the Go folks.  It seems to me that
there are many different solutions that work for other libraries, but
I'm not going to go into details here, except to mention that what we
have now doesn't work very well.

The second issue was I then went to the $GOPATH/src/launchpad.net/goose
location and did a bzr pull there.  That brought me up to rev 60.  But
the tests still failed.  After talking with someone on irc then a
hangout I found that rev 60 was way old, and they were up to rev 75.
What had happened was that when I originally got juju-core and its
dependencies, it resolved launchpad.net/goose to be the trunk branch for
goose, which was at that stage lp:~gophers/goose/trunk, and it then
proceeded to use the public location of
(http://bazaar.launchpad.net/~gophers/goose/trunk/).  Since then the
developers of goose created a new branch that is owned by goose-bot
which does landings for the team (which is a good thing), but this then
meant that my install was broken.

I changed the parent location of $GOPATH/src/launchpad.net/goose to be
lp:goose (which gets resolved to bzr+ssh for me as I have a launchpad
login and is significantly faster and less chatty than http), and pulled
again.  Now I'm on the right revision, but I thought it raised two
interesting issues.


1: What is our plan for handling dependencies between libraries [1]
2: Is there a flag for `go get` that tells it to resolve the underlying
branch again?
2a: Can I specify that `go get` should resolve `lp:` branches properly?
 I'm guessing that it should/could use bzrlib to resolve the name for
it, which would mean that if you had a lp login you'd get a faster download.


Tim

[1] Adding a version string to the pathname inside the import statements
is crazy and we should consider something better.