I think it's time to explicitly set Go's
$GO111MODULE environment variable
Go is in the process of transitioning from
the old traditional
approach to organizing Go code to Go modules. I have my opinions
about the fairly rapid speed of this change, but it's clear that
the Go team wants to push this forward, and as we know, what the team wants they usually get (
both this ongoing change and my habit of sometimes using the
development version of Go, I think it's time for me to explicitly
$GOPATH environment variables that
control this behavior. You might want to consider doing this too.
The Go team is clearly going to be changing the default behavior of modules over time. This creates two problems, even for people who don't use the development version of Go. The first one is simply that the behavior you get will change as you update from Go version to Go version. Explicitly setting the relevant environment variables puts the timing of this change under your control; you can do it at Go version update or not, at your option.
(Apart from the bit where '
$GO111MODULE=auto' is changing its
behavior between Go 1.12 and Go 1.13. Probably the change is for
the better, but it makes me annoyed anyway; some people are going
to experience a change in behavior that will break building some
Go code that they use.)
The second problem is that various Go programs that deal with Go
code are likely to change their default behavior as and if they're
rebuilt with newer versions of Go, because they inherit the current
Go's defaults through core packages. This cuts both ways; you can
experience problems if you rebuild a program like
gopls with the latest Go and
then try to use it in an older environment, or if you don't rebuild
a perfectly fine program like
goimports just because
you started using a new version of Go. Up until very recently it
hasn't been important to carefully match the version of Go that
utility programs were compiled with to the version of Go that you
were actually using, so I suspect that a lot of people have older
binaries that they still use.
$GO111MODULE to a suitable value for your
environment doesn't fix all of the problems here, but it does help
reduce the variation in what happens; at least you're explicitly
telling tools what you want. Setting
$GOPATH too isn't currently
necessary, but I think it's probably a good insurance against the
PS: I am perpetually making mistakes about how many 1's the environment variable has. I even almost published this entry with the title talking about 'GO11MODULE'. I know why it has three 1's, but I wish it was called something else.
Sidebar: Changes in module behavior is why I stopped using Go tip
I could write a bunch of things, but instead I will just point to my tweets on this: here, here, and especially here. The situation has improved since then; now building Go 1.12 starting from the latest development version of Go (ie, almost Go 1.13) merely reports a bunch of:
go_asm.h:493:33: 'p' exponent requires hexadecimal mantissa
As far as I know, the Go people never promised backward compatibility for the Go toolchain (that you could build older versions of Go with newer toolchains), so they are within their rights here. I just don't have to like it, and I took it as a sign to stop using the development version of Go.
Will I update promptly to Go 1.13 when it gets released? I don't know, but quite possibly not, for the first time in Go releases. I'm tempted to let other people find all of the things that don't build any more with the Go 1.13 default behavior for Go modules.