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

Jump to bottom

go mod tidy fails in older version of Go if new stdlib package is imported #43400

Closed
vearutop opened this issue Dec 28, 2020 · 3 comments
Closed

go mod tidy fails in older version of Go if new stdlib package is imported #43400

vearutop opened this issue Dec 28, 2020 · 3 comments
Labels
FrozenDueToAge GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@vearutop
Copy link
Contributor

What version of Go are you using (go version)?

$ go version
go version go1.15.5 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/viacheslavpoturaev/Library/Caches/go-build"
GOENV="/Users/viacheslavpoturaev/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/viacheslavpoturaev/go/pkg/mod"
GONOPROXY="github.com/vearutop,github.com/fincompare"
GONOSUMDB="github.com/vearutop,github.com/fincompare"
GOOS="darwin"
GOPATH="/Users/viacheslavpoturaev/go"
GOPRIVATE="github.com/vearutop"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.15.5/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.15.5/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/tmp/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/_d/_xxbt6m12_9464smy27byk640000gp/T/go-build847063914=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I've made a package that was importing new go1.16 embed and guarded that import with // +build go1.16, I've also implemented alternative for older versions of Go in the same package and guarded it with // +build !go1.16.

The code passes the build in both go1.15 and gotip (or go1.16beta1). However there is a problem when I run go mod vendor or go mod tidy.

Here is a minimal reproducer: https://play.golang.org/p/1MAM92BgVOT

package main

func main() {
	println("hello!")
}

-- go.mod --
module foo

go 1.15


-- tip.go --
// +build go1.16

package main

import _ "embed"

func init() {
	println("greetings from go1.16")
}

What did you expect to see?

$ go mod tidy
$ go mod vendor
go: no dependencies to vendor
$ gotip mod tidy
$ gotip mod vendor
go: no dependencies to vendor

What did you see instead?

$ go mod tidy
foo imports
        embed: package embed is not in GOROOT (/usr/local/Cellar/go/1.15.5/libexec/src/embed)

$ go mod vendor
foo imports
        embed: package embed is not in GOROOT (/usr/local/Cellar/go/1.15.5/libexec/src/embed)

$ gotip mod tidy
$ gotip mod vendor
go: no dependencies to vendor

I would like to be able to write code for upcoming Go features in advance, but at the same time I'd like to keep module management safe in older versions of Go. For library development I can switch to gotip, but apps that use the library would still run on stable version, and they would suffer from failing go mod tidy during own development.
@vearutop vearutop mentioned this issue Dec 28, 2020
Merged
@oiooj oiooj added GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Dec 29, 2020
@zikaeroh
Copy link
Contributor

zikaeroh commented Dec 29, 2020 •
edited

Another datapoint is golang-migrate/migrate#480, where the new embed and io/fs support was locked behind build tags but failed to tidy both in the migrate module and dependent modules.

@zikaeroh
Copy link
Contributor

Likely, this is a dupe of #40067, though. (Still wish there was a good way to handle new stdlib package additions...)

@bcmills
Copy link
Contributor

bcmills commented Jan 5, 2021

Duplicate of #40067

@bcmills bcmills marked this as a duplicate of #40067 Jan 5, 2021
@bcmills bcmills closed this as completed Jan 5, 2021
@golang golang locked and limited conversation to collaborators Jan 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@vearutop @oiooj @bcmills @gopherbot @zikaeroh