[Canonical-tech] Handling active dependencies in Go
John Arbash Meinel
john.meinel at canonical.com
Sat Dec 22 08:22:14 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
...
> Firstly, the tool does not ever install anything. It just changes
> import paths and checks for consistency.
>
> Secondly, it has no concept of "latest" - it simply changes things
> to use the requested version.
>
> Does that make a difference to your assessment?
>
I'm guessing your tool is intended to be layered on top of 'go get -u'
which has the fundamental problem I described.
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.
The answer on the gonuts thread I linked was:
https://groups.google.com/d/msg/golang-nuts/0avuiWURSQk/X7ywUjn3RPsJ
"Just goven libraries you don't trust to stay compatible."
Goven is here: https://github.com/kr/goven
Essentially this forks all the original import branches to local
paths, and then rewrites the import paths to point to the local
location. (So instead of saying use this branch at revX you download
revX, put it into your local package, and use it there.) Or put
another way, fork upstream so you can have snapshot revisions, rather
than just having a tool that lets you specify what snapshot to use.
So it isn't really about your tool per se, more about the 'go get'
model which grabs the latest change, whether that has been vetted by
juju-core yet or not.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Cygwin)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlDVbbYACgkQJdeBCYSNAANd1gCgtcnRZKIXYectNZ1+HqGFTXNy
BJcAnR0Gvt7Opv1mI6wLNLDro25z3Zo3
=s4g7
-----END PGP SIGNATURE-----
More information about the Juju-dev
mailing list