One advantage of Go modules will be less mess in
One of the things coming in Go 1.11 is (experimental) support for
'vgo' package versioning; you
can read some (in-progress) documentation here and here.
One of the reasons I'm looking forward to projects adopting it is
that it holds great promise for cleaning up my
The problem with my
$HOME/go/src currently is that it mingles
together programs (and sometimes packages) that I'm actively using
and tracking along with their various, assorted, and ever-changing
dependencies. I care about the programs but not the dependencies,
but with them co-mingled it's hard to keep either straight and thus
hard to notice and clean up when a dependency is no longer needed.
I generally only notice when I spot pending updates
that are still there even after I '
go get -u' all of the actual
programs I'm using. In a 'vgo' world, the dependencies will get
downloaded and stored in a separate area from the actual packages
I'm building; I can purge that area every so often if I want to.
(Of course doing this purge is slightly risky, since a dependency might have removed its canonical master version. It would be nice if Go would track what dependencies in my cache are needed by what (and how recently), but I don't really expect that to happen.)
I was going to say something about how the new module aware behavior
go get' is not ideal for my case, but now that I read the
documentation I'm not sure of that because I'm not sure I understand
how using '
go get' to just fetch and build a program is supposed
to work now. I suspect that there's going to be some behavior changes
as people talk to the Go developers (and I also rather suspect that
the Go developers will find broad objections to getting rid of
support for things without
go.mod files). In any case it looks
like I won't be able to make any sort of near term transition; this
is instead going to be a long term kind of thing.
(Modules would directly help us with something at work, except that we're going to be on Go 1.10 for years to come because that's what Ubuntu 18.04 comes with.)
(I've sort of written about the clutter issue before in this entry.)
Sidebar: How I want a module-aware '
go get' to behave
Basically I want a mode where Go prefers being module enabled if
go.mod available but falls back to the current behavior
if there isn't. For '
go get', this would mean downloading the
$GOPATH/src as it does today (because there's no other
good place to put it), then either getting its dependencies as
modules (when it has a
go.mod) or fetching them into
as today (if there's no
go.mod), then building using the appropriate
bits (either module aware or not). This would provide an essentially
transparent upgrade path as Go programs that I build start migrating
to using Go modules and having a
(Right now it's not clear to me how you're supposed to correctly
fetch and build a Go program that uses