Versioning issues with juju-core and goose

[David Cheney]

Hi Tim,

The very short answer to this long discussion, is

rm -rf $GOPATH/src/launchpad.net/goose
go get -u -v launchpad.net/juju-core/...

You are completely correct that we are hitting the limits of the way the 
go tool manages dependency versions (that is, not at all), and have 
resorted to an email semaphore.

I have setup a daily build so at least something is building in a fresh 
environment every time. 
https://code.launchpad.net/~dave-cheney/+recipe/juju-core-daily

I believe that we can structure or bisect the juju-core project in a way 
that pushes this integration issues up to the final commands (juju, 
jujud) to reduce the pain as work providers starts to kick in in parallel.

Cheers

Dave

On 15/02/13 12:07, Tim Penhey wrote:
> 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.u
>
> 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.
>