I vote for KR's godep On Tue, Jun 3, 2014 at 8:21 PM, Nate Finch <[email protected]> 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 <[email protected]> wrote: >> >> On 3 June 2014 00:13, Nate Finch <[email protected]> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
