Being good citizens with our external repos

Gustavo Niemeyer gustavo at niemeyer.net
Tue Jun 3 17:29:51 UTC 2014


That's all spot on: godep and versioning the API for compatibility
purposes are orthogonal concepts, versioning the API for compatibility
purposes _helps_ godep's case, and changing import paths is trivial.

I don't personally mind if you use gopkg.in specifically or not, but
I'd strongly recommend adopting some form of compatibility promise so
that the rich library of juju can be trusted upon, both inside and
outside of Canonical.


On Tue, Jun 3, 2014 at 12:21 PM, Nate Finch <nate.finch at canonical.com> wrote:
> Ian makes a good point about repeatable builds.  I had actually come to the
> same conclusion as Rog overnight, that they are orthogonal, so we can do
> both.  I agree with Rog, moving to Keith Rarick's godep is probably the
> right move.  It has a lot more usage than Rog's godeps, and I think avoids
> some of the problems we've seen with godeps.
>
> I think the way we constantly break the APIs of our packages right now is
> awful.  No one will rely on our code, because our code isn't reliable.  I,
> myself, would not even rely on our code, and I think that's quite a shame.
> This is a bad foot to put forward, and it's relatively easy to avoid.
>
> Yes, changing versions of a package causes some code churn, but often times,
> if you have to change the import path, you're going to have to change the
> code that uses it, since by definition, you're breaking the API.  And
> changing one or two characters in the import statement of even a large
> number of files is not really a huge deal, especially since it can be done
> programmatically.


gustavo @ http://niemeyer.net



More information about the Juju-dev mailing list