[Canonical-tech] Handling active dependencies in Go

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-01-08 13:02, roger peppe wrote:
> On 22 December 2012 08:22, John Arbash Meinel
> <john.meinel at canonical.com> wrote:
>> We can work around it, by being disciplined as a library
>> developer. You still have the state where the code using the
>> library only builds because the library didn't accidentally
>> commit a change that broke things.
> 
> Forgive me for not being familiar with more usual versioning
> systems, but wouldn't that be true in other systems too, if you
> commit a change that modifies an existing version?
> 

You can't commit a change that modifies "an existing version" in most
systems. For example, buildout allows you to specify the specific
revision (not just the branch). Or you specify a specific released
version (via a tarball).

It is true that if you re-use v1.1.1 for 2 tarballs (or whatever) you
could run into problems.

However, 'go get' only allows you to specify a branch, without
specifying a specific revision. There have been proposals about
including the revision in the URL (see the original email at:
https://groups.google.com/d/topic/golang-nuts/0avuiWURSQk/discussion
)

There is an option to take that next step, and create a branch for
every revision that we want to use. Its possible, but quite a bit
heavier weight than we are used to. Also note, it isn't possible to
just take trunk and release it as 1.1.1, because if the import URL is
in the juju-core code, it *also* needs to be in the 1.1.1 branch of
goose. (otherwise when "launchpad.net/goose/nova" tries to import
"launchpad.net/goose/identity" it will get something different than
juju-core importing "launchpad.net/goose/1.1.1/identity")

So to do a release, we need to rename all the imports inside goose,
test that it still works, push it to the new URL, and then update
juju-core to also rename all of its imports.

Launchpad uses both 'sourcedeps' for things it deploys from branches
and buildout's 'versions.cfg' for things it deploys using eggs. To
update a source branch, you commit it to trunk, and then the diff in
launchpad is:

- -loggerhead lp:~loggerhead-team/loggerhead/trunk-rich;revno=472
+loggerhead lp:~loggerhead-team/loggerhead/trunk-rich;revno=473

Or:
- -testtools = 0.9.14
+testtools = 0.9.15

(aka, a 1 line change)

Compare that to the diffs I did put up:
https://code.launchpad.net/~gophers/goose/unstable-001/+merge/140140
https://code.launchpad.net/~jameinel/juju-core/goose-unstable-001/+merge/140141

Which is 8 lines in juju-core and 47 lines in goose.

That is all scriptable (and probably helped by your program), but it
is a lot more overhead than 1 line change to a config file. (Not to
mention the overhead of actually creating the 0.0.10 branch, and
publishing to it, etc.)

The go version is ok for a *series* (aka a real branch), but it is
just not usable at a snapshot (aka revision) level (IMO).

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Cygwin)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDsAfcACgkQJdeBCYSNAAN0kQCgpyqTOvp1PCz5K5KFYcnuNHzM
vUcAoKb4dJ7PhNjPfCANNIxYreD74kw6
=S4Mj
-----END PGP SIGNATURE-----