Versioning issues with juju-core and goose

[Tim Penhey]

On 15/02/13 14:28, David Cheney wrote:
> 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/...

That seems quite heavyweight.

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

What are the plans within the Go language team to address this issue?

> 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

Cool.

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

I'm not sure what you are getting at here.


What I've done in the past for projects that have dependent libraries
managed in branches that aren't necessarily released is to make a script...

Also worthwhile for those that don't realise, you can do something like
this:

  $ cd $GOPATH/src/launchpad.net/goose
  $ bzr pull --remember lp:goose

And this will change the parent branch from

  http://bazaar.launchpad.net/~gophers/goose/trunk (or goose-bot)

to

  bzr+ssh://bazaar.launchpad.net/+branch/goose

This +branch redirect works server-side for bzr+ssh (I know because I
wrote it), and will always point to the trunk branch for goose, which
means it would catch similar problems again.

Unfortunately the +branch doesn't work for http (there is history there...).

Tim