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: go mod tidy error when importing std package in later go version #40067

Open
mvertes opened this issue Jul 6, 2020 · 4 comments
Open

cmd/go: go mod tidy error when importing std package in later go version #40067

mvertes opened this issue Jul 6, 2020 · 4 comments
Milestone

Comments

@mvertes
Copy link

@mvertes mvertes commented Jul 6, 2020

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

$ go version
go version go1.13.12 linux/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
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/marc/.cache/go-build"
GOENV="/home/marc/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/marc/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/marc/sdk/go1.13.12"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/marc/sdk/go1.13.12/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/marc/go/src/github.com/containous/yaegi/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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build070856350=/tmp/go-build -gno-record-gcc-switches

What did you do?

consider a sample module with a following file sample.go:

// +build go1.14

package sample

include _ "hash/maphash"       // this package exists in go1.14 but not in go1.13

and a go.mod:

module example.com/sample

go 1.12

And then in this module, running the following command:

go1.13.12 mod tidy

What did you expect to see?

no errors

As hash/maphash package is not present in go1.13 (introduced in go1.14), but the sample.go files should be skipped by go1.13 thanks to the build tag // +build go1.14

What did you see instead?

github.com/containous/yaegi/stdlib imports
        hash/maphash: malformed module path "hash/maphash": missing dot in first path element

I believe that a similar issue occurs in the latest release, maybe with a different error message.

@jayconrod jayconrod changed the title go mod tidy not following go version build constraints cmd/go: go mod tidy not following build constraints for go version Jul 6, 2020
@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Jul 6, 2020

This is mostly working as intended, but the error seems very frustrating.

go mod tidy ignores build constraints when deciding what dependencies are needed. If it didn't, it would remove platform-specific dependencies (for example, modules providing packages only imported from files with // +build windows). That would be frustrating for teams working in mixed environments. (As an exception, files with the ignore tag are still excluded, as are files in testdata directories or directories starting with . or _).

In this case though, tidy in 1.13 treats hash/maphash as a regular import and reports an error. Since there's no dot in the first path element, and there's no required module that could provide that package, perhaps tidy should assume it's a standard package in a future version of Go and ignore it.

cc @bcmills @matloob

@jayconrod jayconrod changed the title cmd/go: go mod tidy not following build constraints for go version cmd/go: go mod tidy error when importing std package in later go version Jul 6, 2020
@jayconrod jayconrod added this to the Go1.16 milestone Jul 6, 2020
@jayconrod jayconrod added the modules label Jul 6, 2020
@mpl
Copy link
Contributor

@mpl mpl commented Jul 8, 2020

By the way, this problem (as expected) also occurs with go mod vendor.

@bcmills
Copy link
Member

@bcmills bcmills commented Jul 17, 2020

I'm not sure that burying the error would be a good idea: we can't in general tell whether the missing hash/maphash is a new standard-library package, or a missing dependency that should be slotted in using a replace directive.

I would be more comfortable with a more narrowly targeted fix. For example, perhaps we should only ignore plausibly-standard-library imports if they occur in files that would normally be excluded by a build constraint.

@bcmills
Copy link
Member

@bcmills bcmills commented Jul 17, 2020

example.com$ go1.13.14 build

example.com$ go1.14.6 build

example.com$ go1.13.14 mod tidy
example.com imports
        hash/maphash: malformed module path "hash/maphash": missing dot in first path element

example.com$ go1.14.6 mod tidy

-- all.go --
package example
-- example114.go --
// +build go1.14

package example

import _ "hash/maphash"
-- go.mod --
module example.com

go 1.14
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
4 participants
You can’t perform that action at this time.