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 · 16 comments
Closed
Labels

Comments

@markbates
Copy link

@markbates markbates 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
Contributor

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

@markbates markbates commented Feb 27, 2019

@bradfitz

This comment has been minimized.

Copy link
Contributor

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

@lukasschlueter lukasschlueter 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
Contributor

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

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

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

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

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

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

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

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

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

@markbates markbates commented Feb 27, 2019

Thanks

gopherbot pushed a commit that referenced this issue Feb 27, 2019
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

@gopherbot gopherbot 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 mentioned this issue Mar 12, 2019
gopherbot pushed a commit that referenced this issue Mar 13, 2019
…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
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
@scode scode mentioned this issue May 3, 2019
marstr added a commit to marstr/baronial that referenced this issue May 6, 2019
This is to work around golang/go#30446
@marstr marstr mentioned this issue May 6, 2019
marstr added a commit to marstr/baronial that referenced this issue May 6, 2019
This is to work around golang/go#30446
dynamix added a commit to remerge/go-service that referenced this issue Jun 14, 2019
@almogdepaz

This comment has been minimized.

Copy link

@almogdepaz almogdepaz commented Jul 7, 2019

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

@GeorgeMac GeorgeMac mentioned this issue Jul 17, 2019
3 of 3 tasks complete
leighmcculloch added a commit to stellar/go that referenced this issue Sep 3, 2019
Converts the mono repo from using the `dep` package manager to using the [go mod](https://github.com/golang/go/wiki/Modules) that has become the standard dependency manager in recent releases of Go.

Make the monorepo more accessible to Go developers using standard Go tooling. Modules will be enabled by default in Go 1.13, and were enabled by default when not using a GOPATH in Go 1.11+.

Summary of changes:
* [x] Add a `go.mod` file that contains the same dependencies and dependency versions/hashes/sources.
* [x] Add a `go.sum` which is the smallest set of hashes required to validate that the dependencies at those versions remain consistent.
* [x] Add a `go.list` which is a way for us to visibly see when our dependencies change. Note: This is not a standard file, but is something we can use to validate reproducibility until the `go mod` commands provide something similar.
* [x] Update CircleCI and TravisCI builds so that they succeed
* [x] Update CircleCI and TravisCI builds so that they fail if any of the above `go.*` files are out of date.
* [x] Update documentation within the repository
* [x] Test that other projects can import this repo. (This will be much easier, unfortunately, to test after merging, but I am currently attempting to test this before merging.)
* [x] Remove the existing `dep` files, `Gopkg.toml` and `Gopkg.lock`. (This will occur just before merging.)

Known limitations & issues:
This change bumps our minimum supported version of Go to 1.11.4. Versions prior to that version contained a bug when Modules are in use that prevented the importing of some packages. There are more details about the issue here: golang/go#30446 (comment).

All changes:
* all: update ci config to use modules instead of dep
* all: go mod init
* all: go mod tidy -v
* all: go get github.com/gobuffalo/packr@v1.12.1
* all: go get github.com/spf13/cobra@9c28e4bbd74e
* all: go mod tidy -v
* all: go get github.com/BurntSushi/toml@99064174e013
* all: go get github.com/spf13/viper@db7ff930a189, go mod tidy
* all: go get github.com/mitchellh/mapstructure@2caf8efc9366, go mod tidy
* all: go get github.com/kr/pretty@e6ac2fc51e89, go mod tidy
* all: go get github.com/kr/text@e373e137fafd, go mod tidy
* all: go get github.com/sirupsen/logrus@070c81def33f, go mod tidy
* all: go get github.com/spf13/pflag@4bd69631f475, go mod tidy
* all: go get github.com/spf13/jwalterweatherman@3d60171a6431, go mod tidy
* all: go get github.com/magiconair/properties@v1.5.4, go mod tidy
* all: go get github.com/spf13/cast@4d07383ffe94, go mod tidy
* all: go get github.com/davecgh/go-spew@5215b55f46b2, go mod tidy
* all: go get github.com/stretchr/testify@976c720a22c8, go mod tidy
* all: go get github.com/stretchr/objx@1a9d0bb9f541, go mod tidy
* all: commit go.sum file
* all: commit go.list file generated with go list -m all > go.list
* all: download dependencies in an earlier step
* all: change the install process for staticcheck to leverage modules
* all: add check of dependencies
* all: add checks and tests running with go1.13rc1
* all: allow install of a newer versions of some packages for buster images
* all: do a check of deps before building for publishing
* doc: update readmes with new building instructions
* all: update travis.yml with modules and go1.13rc1
* all: update dockerfiles with modules
* all: set go.mod's go directive to go 1.11
* all: run travis builds on the latest minor release of each
* doc: increase min version of Go to 1.11.4
* all: cache go mod download
* all: use new git repo for gocheck
* all: skip go.sum checks for go 1.11.* because it is inconsistent with other versions of go
* all: remove reference to dep in dockerfile
* all: remove reference to dep in horizon dockerfile
* all: remove curl in horizon dockerfile because was only needed for dep
* doc: remove mention of go-dep
* doc: remove mention of dep in developing documentation
* doc: update min Go required to go1.11.4
* doc: improve developer building instructions
* all: install postgres-client-9.6 via postgres apt
* all: go get github.com/rcrowley/go-metrics@51425a2415d2, go mod tidy
* all: remove duplicate steps from poor copy and paste
* all: go get golang.org/x/net@ba9fcec4b297b415637633c5a6e8fa592e4a16c3, go mod tidy
* all: use a cache key that references go.mod too
* all: remove dep files: Gopkg.*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.