Wandering Thoughts archives


I think it's time to explicitly set Go's $GO111MODULE environment variable

Go is in the process of transitioning from the old traditional $GOPATH 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 (try excepted). Given both this ongoing change and my habit of sometimes using the development version of Go, I think it's time for me to explicitly set the $GO111MODULE and $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.

Explicitly setting $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 future.

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.

programming/GoTimeToSetGO111MODULE written at 22:34:42; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.