Re: Versioned packages and testing dependencies
That's an interesting observation and I think I agree. The general rule is probably something like this: - If a type is part of the exported API of a versioned package and the package is changed to import that type from somewhere else, the package's version must be incremented. Given that versions usually apply to repositories, not packages, that does unfortunately mean that all the repositories which export testing functionality using gocheck need to have their versions incremented. I don't think it all has to happen at the same time, because APIs remain stable. It does mean that juju-core can only be updated after all of its dependencies have been updated though. cheers, rog. On 22 September 2014 12:14, John Meinel j...@arbash-meinel.com wrote: So Bogdan Teleaga was kind enough to put in the effort to move all of our source trees to start importing from gopkg.in/check.v1 rather than depending on labix.org/gocheck. However, this means that if we land those changes, code that depends on the testing infrastructure provided by those packages will break because a labix.org/gocheck.Suite is not a gopkg.in/check.v1.Suite. And even further, Checkers are different (so we have to update github.com/juju/testing/checkers/ before other code.) Since we're doing versioned stable APIs I'm wondering if this means things need a version bump. I *think* the answer is yes, because if you just did: go get gopkg.in/juju/charm.v3 Before the change, you could run cd github.com/juju/juju; go test ./... but if we change just charm.v3 but not juju/juju then go test ./... just breaks. Thus, changing your testing infrastructure while it doesn't change your API it changes your *test interface* which makes it an unstable API break. And we have the unfortunate process that *all* of our code is tested via 'gocheck' which means that we have to update-the-world to rev its import. Certainly I'd rather not do the work if we don't have to, so I'd like other people's input if we feel we have to. John =:- -- 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: Versioned packages and testing dependencies
John, Roger, This situation right here is why I am strongly opposed to the gopkg.in versioning model. I recommend reverting to the original launchpad location. Dave On Mon, Sep 22, 2014 at 9:56 PM, roger peppe roger.pe...@canonical.com wrote: That's an interesting observation and I think I agree. The general rule is probably something like this: - If a type is part of the exported API of a versioned package and the package is changed to import that type from somewhere else, the package's version must be incremented. Given that versions usually apply to repositories, not packages, that does unfortunately mean that all the repositories which export testing functionality using gocheck need to have their versions incremented. I don't think it all has to happen at the same time, because APIs remain stable. It does mean that juju-core can only be updated after all of its dependencies have been updated though. cheers, rog. On 22 September 2014 12:14, John Meinel j...@arbash-meinel.com wrote: So Bogdan Teleaga was kind enough to put in the effort to move all of our source trees to start importing from gopkg.in/check.v1 rather than depending on labix.org/gocheck. However, this means that if we land those changes, code that depends on the testing infrastructure provided by those packages will break because a labix.org/gocheck.Suite is not a gopkg.in/check.v1.Suite. And even further, Checkers are different (so we have to update github.com/juju/testing/checkers/ before other code.) Since we're doing versioned stable APIs I'm wondering if this means things need a version bump. I *think* the answer is yes, because if you just did: go get gopkg.in/juju/charm.v3 Before the change, you could run cd github.com/juju/juju; go test ./... but if we change just charm.v3 but not juju/juju then go test ./... just breaks. Thus, changing your testing infrastructure while it doesn't change your API it changes your *test interface* which makes it an unstable API break. And we have the unfortunate process that *all* of our code is tested via 'gocheck' which means that we have to update-the-world to rev its import. Certainly I'd rather not do the work if we don't have to, so I'd like other people's input if we feel we have to. John =:- -- 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 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: Versioned packages and testing dependencies
On 22 September 2014 12:59, David Cheney david.che...@canonical.com wrote: John, Roger, This situation right here is why I am strongly opposed to the gopkg.in versioning model. I recommend reverting to the original launchpad location. Dave I understand your concern - having multiple versions of the same package bundled into the same binary and/or type clashes like this is not ideal. But actually think that this is just gopkg.in working as intended, and I still think that's a good thing. Without gopkg.in, it's not possible for the authors of a package to make go get continue to work in the face of changing dependencies. I think that pinning dependencies in a main package is reasonable, as there's no chance of conflicts, and it's great for reproducibility, but using version pinning in every repository seems like a recipe for impossible-to-fix version clashes to me. Using gopkg.in has made it possible, for example, for us change the charm package API considerably without disrupting any of its various clients. Note that the rule I proposed above is only concerned with *exported* types from versioned packages, something that's not that common. In the gocheck case there are only four repositories which juju imports that would need a new version (for the record: github.com/joyent/gocommon/testing, github.com/juju/cmd/cmdtesting, github.com/juju/testing, github.com/juju/txn/testing, gopkg.in/juju/charm.v3/testing) There is still a potential problem even with internal-use-only imports, particularly with respect to packages that use a registry pattern. I think there's room for a tool here that shows potentially clashing dependencies (govers can do something similar, but only for a single package). I still think gocheck solves more problems than it creates. Stable APIs are a Good Thing. cheers, rog. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
