Being good citizens with our external repos

[Nate Finch]

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.

-Nate


On Tue, Jun 3, 2014 at 4:07 AM, roger peppe <rogpeppe at gmail.com> wrote:

> On 3 June 2014 00:13, Nate Finch <nate.finch at canonical.com> wrote:
> > Right now, we change tip on our repos outside of Juju-core with breaking
> API
> > changes.  This is not the way to make packages that others can use and
> > depend on.  Since we are in the process of moving many/most/all of these
> > dependencies to github, I think it would be an opportune time to start
> being
> > better about how we maintain these projects.
> >
> > The main way to do this in Go is to use versioned URLs, the way
> > labix.org/v2/mgo and gopkg.in use them.  I suggest we set up a facility
> to
> > do this so that if other people are using our code, we won't break them
> > every time we need to change the API of one of our packages.
> >
> > It also would mean reduced reliance on godeps (in theory we could get to
> the
> > point of not needing it at all), which would be a good thing.
>
> No, use of godeps (or Keith Rarick's godep, which I think we should
> probably
> move towards using) is orthogonal to the use of versioned URLs.
>
> Versioned URLs give us (or provide to others) stable APIs, so you are
> guaranteed
> to be able to *compile* packages, but they don't give or provide guaranteed
> *behaviour*, which is crucial for us to get repeatable builds.
>
> So while I agree that it would be nice to move towards a versioned Juju
> API, we still need to use godeps.
>
> FWIW, I think it would be more than nice - it's actually very important
> that
> we start to export versioned APIs, at least for selected parts of the
> project,
> because external projects will start to depend on the Juju API and
> will need it to be stable.
>
> Initially, I'd suggest that we at least provide a stable API that
> allows third-party
> code to:
>
> - bootstrap, open and destroy environments
> - interact with the API
>
> It might be a good moment to stand back and consider what we actually
> want that package API to look like and perhaps making a package that
> layers on
> top of existing code that provides that.
>
>   cheers,
>     rog.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140603/88b49241/attachment.html>