[Canonical-tech] Handling active dependencies in Go

[John Arbash Meinel]

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

...

>> 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)
> 
> (genuine question) What happens about source code that still
> depends on the old version? Does it search the revision history for
> the right version?

If you checkout an old version of launchpad and build it, it will
install the old version of testtools (and loggerhead) as specified in
the launchpad configuration.[1]

It isn't quite "searching" as much as "grab the exact version that was
specified".

Already today, I cannot rollback juju-core to check a regression,
because the dependencies will no longer match, and I don't have a way
to know what version were actually used.



> 
>> 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.
> 
> I'm not sure that the human-time overhead is necessarily that
> different.

Actually, it is another tool you have to learn (govers, etc) which has
a fairly high cognitive overhead. And failure mode.

> 
>> (Not to mention the overhead of actually creating the 0.0.10
>> branch, and publishing to it, etc.)
> 
> Isn't that just a single "bzr push"?

It is. But note that you *should* do the push and full release dance
anytime you want to use newer goose code in juju-core. Without that,
you can't safely rollback juju-core to a tested configuration. (I'm
not pushing for it today with goose, because you already can't do it
because of goamz, goyaml, etc.) [I believe today you cannot revert
earlier that juju-core 782 because that brought in updated goamz code,
there are also goose incompatibilities]

> 
>> 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).
> 
> I definitely understand your concerns, and I see that other systems
> might make the overhead of releasing smaller, but I still think
> that there are significant advantages to having all Go code declare
> its dependencies explicitly, including the API version.
> 
> If we're to move forward with the conventional Go way, there's one 
> issue I'm not entirely clear about: should we use immutable
> versions corresponding to each released change to the source, or
> mutable versions corresponding to each API change?
> 
> The former has the advantage that you know exactly what you're 
> importing and testing against, but you incur the release overhead 
> every time you want to make the changes available to juju-core. The
> latter means that there's less chance of version skew and you can
> update internal details without the requirement to change all
> clients, but you run the risk of breaking working clients with a
> code change that's not careful enough.

Right.


> 
> It might be possible, I suppose, to use a combination of both 
> approaches - provide a versioned path that represents an API
> version, and also provide a path that represents a particular
> source version. That may well be the worst of both worlds though
> :-)
> 
> Aside: it's a pity that "go tool api" doesn't work with general
> packages.
> 

John
=:->

[1]  IIRC it does this by playing games with site.py configuration at
runtime, and using a custom 'py' script. It removes all default search
paths, and sets each path manually. One could imagine a build tool
that built up GOPATH based on explicit locations for versions of
dependencies.


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

iEYEARECAAYFAlDsF+4ACgkQJdeBCYSNAAOfggCfXwSDCGO4xrNmBv9ZFIn0M/sh
GiIAoLbzrxwJnH1FNCV2cyTSzP9M334k
=knAV
-----END PGP SIGNATURE-----