Re: Being good citizens with our external repos
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 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 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Being good citizens with our external repos
I vote for KR's godep On Tue, Jun 3, 2014 at 8:21 PM, Nate Finch 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 wrote: >> >> On 3 June 2014 00:13, Nate Finch 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@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Being good citizens with our external repos
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 wrote: > On 3 June 2014 00:13, Nate Finch 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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Being good citizens with our external repos
On 3 June 2014 00:13, Nate Finch 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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Being good citizens with our external repos
I agree with the general thrust of the point being made but until Go (or more accurately he Go community) agrees on a sane dependency management model I can't see how we can move away from godeps. Even if we attempt to use versioned import URLs (which make me very sad due to the pointless code churn and overhead they introduce), it is utter madness to depend on tip of the branch. Builds should be deterministic, repeatable and stable. That is impossible if we just pull in tip each time. Thinking that the import URL not changing means that there will be no subtle breakages in API behaviour is dangerous. It's just a whole world of unnecessary hurt not depending on a known revision. So in my view godeps needs to be with us for a while longer. On 03/06/14 09:13, Nate Finch 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. > > Thoughts? > > > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Being good citizens with our external repos
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. Thoughts? -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
