Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: "module requires Go 1.12" error when building with Go 1.11.3 or earlier #30446

Closed
markbates opened this issue Feb 27, 2019 · 15 comments

Comments

Projects
None yet
6 participants
@markbates
Copy link

commented Feb 27, 2019

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
@bradfitz

This comment has been minimized.

Copy link
Member

commented Feb 27, 2019

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.

@markbates

This comment has been minimized.

Copy link
Author

commented Feb 27, 2019

@bradfitz

This comment has been minimized.

Copy link
Member

commented Feb 27, 2019

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.

@lukasschlueter

This comment has been minimized.

Copy link

commented Feb 27, 2019

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?

@bradfitz

This comment has been minimized.

Copy link
Member

commented Feb 27, 2019

Oh, I don't remember that part. Maybe this is a bug, then. @bcmills?

@bradfitz

This comment has been minimized.

Copy link
Member

commented Feb 27, 2019

It looks like you were using go 1.11.0. Can you try a more recent Go 1.11.x version?

@thepudds

This comment has been minimized.

Copy link

commented Feb 27, 2019

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.

@thepudds

This comment has been minimized.

Copy link

commented Feb 27, 2019

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.12

@thepudds thepudds added the modules label Feb 27, 2019

@thepudds thepudds changed the title module requires Go 1.12 cmd/go: module requires Go 1.12 Feb 27, 2019

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Feb 27, 2019

What 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.

@markbates

This comment has been minimized.

Copy link
Author

commented Feb 27, 2019

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.

@thepudds

This comment has been minimized.

Copy link

commented Feb 27, 2019

@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.

@thepudds thepudds changed the title cmd/go: module requires Go 1.12 cmd/go: "module requires Go 1.12" error when building with Go 1.11.3 or earlier Feb 27, 2019

@gopherbot

This comment has been minimized.

Copy link

commented Feb 27, 2019

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

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Feb 27, 2019

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.

@markbates

This comment has been minimized.

Copy link
Author

commented Feb 27, 2019

Thanks

gopherbot pushed a commit that referenced this issue Feb 27, 2019

doc/go1.12: new go line in go.mod can break builds with Go 1.11 - 1.11.3
Fixes #30446

Change-Id: If069f72fa9735f839df92f3ede3bf7b6d7a695a5
Reviewed-on: https://go-review.googlesource.com/c/164317
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
@gopherbot

This comment has been minimized.

Copy link

commented Feb 27, 2019

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

@kpurdon kpurdon referenced this issue Mar 12, 2019

Merged

Go Modules #394

gopherbot pushed a commit that referenced this issue Mar 13, 2019

[release-branch.go1.12] doc/go1.12: new go line in go.mod can break b…
…uilds with Go 1.11 - 1.11.3

Updates #30446

Change-Id: If069f72fa9735f839df92f3ede3bf7b6d7a695a5
Reviewed-on: https://go-review.googlesource.com/c/164317
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit e32203f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/164318

maruel added a commit to google/periph that referenced this issue Mar 18, 2019

go.mod: add 'go 1.11' line
This is the recommendation at golang/go#30446

Otherwise 'go 1.12' gets added automatically by the go tool from 1.12
toolchain, which makes it incompatible with go 1.11.0 to 1.11.3 (!)

Since periph aims to keep some level of backward compatibility, add the
line as recommended at https://golang.org/doc/go1.12#modules :
  go mod edit -go=1.11

@markbates markbates referenced this issue Mar 22, 2019

Merged

Add region flag #9

@scode scode referenced this issue May 3, 2019

Merged

go get -u #28

marstr added a commit to marstr/baronial that referenced this issue May 6, 2019

Adopting Go 1.12
This is to work around golang/go#30446

@marstr marstr referenced this issue May 6, 2019

Merged

Adopting Go 1.12 #14

marstr added a commit to marstr/baronial that referenced this issue May 6, 2019

Adopting Go 1.12
This is to work around golang/go#30446
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.