Versioning issues with juju-core and goose

[David Cheney]

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

Yes. It will fix your problem right now, but the solution gets more 
complicated if you've used cobzr on both juju-core and goose. I've had 
one days changes eaten by using go get -u on a cobzr repo and have never 
tried again.

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

Although this is a common theme on the mailing list, there have been no 
public comments from the Go authors. Quite a few wrappers and packaging 
have been proposed by community members, none of them are really a good 
fit for our requirements.

Back in the pre go 1.0 days, I worked on an addition to the (then 
leading) go-gb build tool which allowed people to 'vendor' dependencies. 
Combined with some sort of bzr external (no idea if or what it is called 
in bzr) that may be one solution to the problem.

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

I think it is possible to restructure the juju-core project, probably 
splitting it into three projects which would push the requirement to 
actively track so many dependencies down to the final integration stage, 
the commands. I intended to raise this at last weeks call, but I 
deferred it as the agenda was very full.

Dave