move towards using gopkg.in

[David Cheney]

I don't want to introduce another thing to break CI, we already pull
from github which is bad enough, but going via gopkg.in introduces an
additional point of failure which can further reduce the already
bullet ridden credibility of our CI.

I also don't want to start introducing versioned import paths into
Juju without serious discussion of how to prevent two different
versions of a package transitively.

We do not (thank $DEITY) have this problem today, thanks to gopdes,
and I don't want to introduce it tomorrow.

I am cognisant of the argument for stable API's, but I do not feel
that gopkg.in outweighs the risk and cost of having to be constantly
vigilant that two versions of a gopkg.in redirected package do not
slip into the same binary.

I am NOT LGTM on any change that introduces gopkg.in redirected import
paths until the issue above is resolved.

Dave

On Tue, Jul 8, 2014 at 3:37 AM, roger peppe <roger.peppe at canonical.com> wrote:
> I think it would be a good idea if we moved towards
> defining stable APIs, particularly for repositories
> outside github.com/juju/juju itself.
>
> In particular, I hope we can make "go get" work
> without people needing to jump through the godeps hoop.
> This is a particular issue as we move towards having
> more external commands in different repositories.
>
> An additional motivation is that I would like us to provide APIs
> to enable other people to use the juju code as a stable base on
> which to build their own Go programs that use juju functionality.
>
> I had a particular use case for this recently when we
> made several breaking changes to the github.com/juju/charm
> API. If we had just changed the API, without changing juju/juju and
> juju/charmstore simultaneously to use new API, there would have
> no way to have both the charm store and juju itself both
> building from the same repository.
>
> gopkg.in is a decent solution to this problem, I believe, and
> a good direction to head in general.
>
> After discussion with (and approval by) several juju-core members,
> we have pushed the new API to gopkg.in/juju/charm.v2 (the
> code now lives in the "v2" branch at github.com/juju/charm).
> The changeover has been no problem. We have been
> able to change the charm store and juju-core at our leisure,
> and we have avoided knowingly breaking any external code too.
>
> It has been pointed out to me that we have not raised
> this issue on the mailing list yet. This is me doing that :-)
>
> If there are any people that think that this is a bad idea, or
> that we should be doing it differently, please speak up now.
>
>   cheers,
>     rog.
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev