cmd/go: "module requires Go 1.12" error when building with Go 1.11.3 or earlier
markbates opened this issue · 16 comments
What version of Go are you using (go version)?
Downloading: https://storage.googleapis.com/golang/go1.11.linux-amd64.tar.gz Extracting archive [command]/bin/tar xzC /home/vsts/work/_temp/1c8530c4-eae3-4887-a554-cae13254c039 -f /home/vsts/work/_temp/86ea4780-4861-4208-9eee-76c050c1dcec Caching tool: go 1.11.0 x64 Prepending PATH environment variable with directory: /opt/hostedtoolcache/go/1.11.0/x64/bin
Does this issue reproduce with the latest release?
No
What operating system and processor architecture are you using (go env)?
go env Output
go1.11.linux-amd64 https://dev.azure.com/markbates/buffalo/_build/results?buildId=412
What did you do?
I rebuilt the go.mod file for gobuffalo/buffalo (https://github.com/gobuffalo/buffalo/pull/1610/files) using go1.12. In doing so it added go 1.12 to the top of the go.mod:
module github.com/gobuffalo/buffalo
go 1.12
When attempting to test this on CI with any variation of GOOS (windows, Mac, linux), go1.11 and GO111MODULES=on, I get errors telling me that module requires Go 1.12
PR: https://github.com/gobuffalo/buffalo/pull/1610/files
CI: https://dev.azure.com/markbates/buffalo/_build/results?buildId=412
What did you expect to see?
I expected my tests to pass as they had previously done before the go.mod file was modified.
What did you see instead?
go build github.com/gobuffalo/buffalo/render: module requires Go 1.12
go build github.com/gobuffalo/buffalo/binding: module requires Go 1.12
go build github.com/gobuffalo/buffalo/runtime: module requires Go 1.12
go build github.com/gobuffalo/buffalo/servers: module requires Go 1.12
go build github.com/gobuffalo/buffalo/worker: module requires Go 1.12
go build github.com/gobuffalo/buffalo/binding: module requires Go 1.12
go build github.com/gobuffalo/buffalo/buffalo/cmd/destroy: module requires Go 1.12
go build github.com/gobuffalo/buffalo/packrd: module requires Go 1.12
go build github.com/gobuffalo/buffalo/genny/grift: module requires Go 1.12
go build github.com/gobuffalo/buffalo/genny/grift: module requires Go 1.12
go build github.com/gobuffalo/buffalo/grifts: module requires Go 1.12
go build github.com/gobuffalo/buffalo/mail/internal/mail: module requires Go 1.12
go build github.com/gobuffalo/buffalo/render: module requires Go 1.12
go build github.com/gobuffalo/buffalo/worker: module requires Go 1.12
So change your module file to say go 1.11.
If you deleted your module, it initializes it to the language version you're working with.
Yes. That's working as designed. That's the mechanism by which we can evolve the language.
If your intention is for your code to have Go 1.11 semantics and work with Go 1.11, declare it there in your go.mod.
https://golang.org/doc/go1.12#modules states the following:
If the go directive for a module specifies a version newer than the toolchain in use, the go command will attempt to build the packages regardless, and will note the mismatch only if that build fails.
Wouldn't that apply in this case, meaning it should still compile with 1.11 in this case?
It looks like you were using go 1.11.0. Can you try a more recent Go 1.11.x version?
I think the issue is the meaning of the go directive changed, and that change was first introduced in 1.11.4 and 1.12.
I believe Go 1.11.4 and higher will build a module that contains version go 1.12 without complaint, whereas earlier 1.11 versions complain with go build github.com/me/hello: module requires Go 1.12.
Here's a short end-to-end example showing 1.11.3 fail and 1.11.4 build succesfully.
# create a .go file
$ cat <<EOF > hello.go
package main
import "fmt"
func main() { fmt.Println("hello") }
EOF
# 'go mod init' in 1.12 sets the 'go.mod' to have 'go' directive value of '1.12'
$ go1.12 mod init github.com/me/hello
$ cat go.mod
module github.com/me/hello
go 1.12
# 1.11.3 fails when you try to build due to the 'go 1.12' in the 'go.mod'
$ go1.11.3 build
go build github.com/me/hello: module requires Go 1.12
# 1.11.4 builds same thing successfully
$ go1.11.4 build
# now force a compilation error with 1.11.4, and see extra message stating 1.12 is required
# (which will in theory be helpful in the future with Go2 changes).
$ echo "BAD COMPILE" >> hello.go
$ go1.11.4 build
# github.com/me/hello
.\hello.go:12:1: syntax error: non-declaration statement outside function body
note: module requires Go 1.12What people say above is correct: when creating a module with Go 1.12, and thereby getting a go 1.12 in your go.mod file, you need to use at least Go 1.11.4 to build the module going forward. Closing because this is working as expected. I agree that this is imperfect but the only other option I see would be to delay all language changes for another six months, which seems severe.
At the very least this should be in some docs somewhere. It's clearly a problem that people are somehow just suppose to just know what versions of Go will work with this change.
@ianlancetaylor one alternative would be for Go 1.12 to set the required Go version to go 1.11 rather than go 1.12, which would sidestep this 1.11-specific transitional issue, and that could be reasonable given there are no language changes in Go 1.12. If language changes land in Go 1.13, then Go 1.13 could set go 1.13, and more generally moving forward the default version set could be the current version of the go tool. However, although in theory such a change could be introduced in a Go 1.12.1, I suspect that might be viewed as too much churn, too inconsistent with future behavior, and/or a ship that has already sailed.
@markbates agreed that a short release note comment or similar could save future headache for other gophers.
Change https://golang.org/cl/164317 mentions this issue: doc/go1.12: new go line in go.mod can break builds with Go 1.11 - 1.11.3
I don't particularly want to hack the Go 1.12 go language. I sent https://golang.org/cl/164317 to update the release notes.
Thanks
Change https://golang.org/cl/164318 mentions this issue: [release-branch.go1.12] doc/go1.12: new go line in go.mod can break builds with Go 1.11 - 1.11.3
@thepudds you saved me lots of time, thanks your diagnosis was spot on.
i had the exact same issue switching from 1.11.2 to 1.11.4 fixed it.