move towards using gopkg.in

[Tim Penhey]

On 08/07/14 09:00, Ian Booth wrote:
>>
>> 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.

I agree.  Godeps (or similar alternative tool) is still needed and
orthogonal to the versioned API imports.

Tim