Being good citizens with our external repos

[David Cheney]

I vote for KR's godep

On Tue, Jun 3, 2014 at 8: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.
>
> -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.
>
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>