Versioned packages and testing dependencies

[roger peppe]

On 22 September 2014 12:59, David Cheney <david.cheney at 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.