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 -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
