Go modules and the problem of noticing updates to dependencies
Now that Go 1.13 has been released, we're moving that much closer to a module-based Go world. I've become cautiously but broadly positive towards Go 1.13 and this shift (somewhat in contrast to what I expected earlier), and I'm probably going to switch over to Go 1.13 everywhere and move toward modules in my own work. Thinking about working in this environment has left me with some questions.
Let's suppose that you have some programs or code that uses third party
packages, and these are generally stable programs that don't really
need any development or change. In the Go module world, the version
of those packages that you use is locked down by your
and won't change unless you manually update, even if new versions
are released. In theory you can keep on using your current versions
forever, but in practice as a matter of good maintenance hygiene
you probably want to update every so often to pick up bug fixes,
improvements, and perhaps security updates. As always, updating
regularly also makes the changes smaller and easier to deal with
if there are problems.
In the pre-module world, how I found out about such updates was
that I ran Go-Package-Store every so often and
looked at what it reported (I could also use gostatus). I also had (and have) tools
like binstale and gobin, which I could use with scripting
to basically '
go get -u' everything I currently had a Go binary
for (which makes some of the problems from my old entry on using
Go-Package-Store not applicable any more).
I'm not sure how to do this in a world of Go modules. Go-Package-Store
works by scanning your
$GOPATH, but with modules the only things
there are (perhaps) your actual programs, not their dependencies.
You can see updates for the dependencies of any particular program
or module with '
go list -u -m all' (in a cryptic format; anything
with a '[...]' after it has an update to that version available),
but I don't think anyone has built anything to do a large scale
scan, try to find out what the changes are, and show them to you.
(The current module behavior of '
go get', '
go list', and company
also seems surprising to me in some areas that complicate interpreting
go list -u -m all' output, although perhaps it's working as
Relying on Go modules also brings up a related issue of what to do
if the upstream source just goes away. In the pre-module world, you
have a full VCS clone of the upstream in your
$GOPATH/src, so you
can turn around and re-publish it somewhere yourself (or someone
else can and you know you can trust their version because it's the
same as your local copy). In the module world you only have a
snapshot of a specific version (or versions) in your
tree or in the Go module proxy you're using. Even if you vendor
things as well, you're not going to have the transparent and full
version history of the original package that you do today, and the
lack of that history will make it harder to do various things to
recover from a disappearing or abruptly changed package.
(I'm a cautious sysadmin who has been around for a while. I've seen all sorts of repositories just disappear one day for all sorts of different reasons.)
(Perhaps someday there will be a Go module proxy that deliberately makes a full VCS clone when you request a module.)
Comments on this page:Written on 06 September 2019.