move towards using gopkg.in

[Ian Booth]

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

I'm somewhat wary of depending on an another "unknown" third party website being
available for our stuff to work. Of course, we also depend already on github and
launchpad etc etc so maybe the point is moot.

I still can't see how we can do away with godeps. The gopkg.in solution may
solve the api versioning issue at a macro level, but without godeps we still
won't get repeatable builds, which is a key requirement for proper configuration
management.