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: 'inconsistent vendoring' error when a user module is located within GOROOT/src #34657

Closed
awnumar opened this issue Oct 2, 2019 · 10 comments
Closed

Comments

@awnumar
Copy link
Contributor

@awnumar awnumar commented Oct 2, 2019

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

$ go version
go version go1.13.1 windows/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
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\ContainerAdministrator\AppData\Local\go-build
set GOENV=C:\Users\ContainerAdministrator\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\go\src\github.com\awnumar\memguard\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\ContainerAdministrator\AppData\Local\Temp\go-build491552814=/tmp/go-build -gno-record-gcc-switches

What did you do?

go get ./...
go build -race -v ./...

What did you expect to see?

Expected the go tool to fetch dependencies and build the project.

What did you see instead?

C:\go\src\github.com\awnumar\memguard>call go get ./... 
go: downloading golang.org/x/crypto v0.0.0-20190927123631-a832865fa7ad
go: downloading github.com/awnumar/memcall v0.0.0-20190930130926-11bbaffc6c8f
go: extracting github.com/awnumar/memcall v0.0.0-20190930130926-11bbaffc6c8f
go: extracting golang.org/x/crypto v0.0.0-20190927123631-a832865fa7ad
go: downloading golang.org/x/sys v0.0.0-20190927073244-c990c680b611
go: extracting golang.org/x/sys v0.0.0-20190927073244-c990c680b611
go: finding github.com/awnumar/memcall v0.0.0-20190930130926-11bbaffc6c8f
go: finding golang.org/x/crypto v0.0.0-20190927123631-a832865fa7ad
go: finding golang.org/x/sys v0.0.0-20190927073244-c990c680b611

C:\go\src\github.com\awnumar\memguard>call go build -race -v ./... 
go: inconsistent vendoring in C:\go\src\github.com\awnumar\memguard:
	go.mod requires github.com/awnumar/memguard  but vendor/modules.txt does not include it.
	run 'go mod tidy; go mod vendor' to sync

This is surprising since the exact same build works on linux, freebsd and osx, and since the project uses modules and has no vendor folder or modules.txt file.

The issue started with the recent go1.13 release and is reproducible on at least two of the packages that I maintain.

A log of the failing build is available here: https://cirrus-ci.com/task/6291981996654592

@andybons

This comment has been minimized.

Copy link
Member

@andybons andybons commented Oct 2, 2019

@andybons andybons added this to the Unplanned milestone Oct 2, 2019
@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Oct 2, 2019

@awnumar, go get does not update the contents of the vendor directory.

Did you run the command suggested by the error message? If so, did it cause go build to subsequently succeed?

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Oct 2, 2019

Ah, go env shows the problem:

set GOROOT=c:\go

GOROOT (in this case, c:\go) is where the Go standard library lives. User code is not intended to be placed there.

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Oct 2, 2019

That said, I suspect https://golang.org/cl/198319 would fix this symptom: it makes the vendor check depend on the presence of the vendor directory rather than the module's location within GOROOT/src.

@bcmills bcmills removed the WaitingForInfo label Oct 2, 2019
@bcmills bcmills changed the title cmd/go: windows: inconsistent vendoring error (dependencies aren't vendored) cmd/go: 'inconsistent vendoring error' when a user module is located within GOROOT/src Oct 2, 2019
@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Oct 2, 2019

(That is to say: this would likely be fixed by #33848.)

@bcmills bcmills changed the title cmd/go: 'inconsistent vendoring error' when a user module is located within GOROOT/src cmd/go: 'inconsistent vendoring' error when a user module is located within GOROOT/src Oct 2, 2019
@awnumar

This comment has been minimized.

Copy link
Contributor Author

@awnumar awnumar commented Oct 2, 2019

@bcmills Running the commands to generate the vendor folder did not fix the issue. Is there an ETA for this patchset?

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Oct 2, 2019

@awnumar, assuming that there are no last-minute objections or unforeseen problems, I'm hoping to get #33848 in to 1.14. It will not be released before then, but you can always build from source (with whatever patches you like) in the meantime.

awnumar added a commit to awnumar/memguard that referenced this issue Oct 4, 2019
@awnumar

This comment has been minimized.

Copy link
Contributor Author

@awnumar awnumar commented Oct 4, 2019

Can confirm moving the working directory to c:\golang fixed the build.

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Oct 9, 2019

The CLs for #33848 have landed, so I believe this should be fixed in gotip (or a go command otherwise built from source at head). Please let us know if you find that is not the case.

@bcmills bcmills closed this Oct 9, 2019
@bcmills bcmills modified the milestones: Unplanned, Go1.14 Oct 9, 2019
avalluri added a commit to avalluri/pmem-CSI that referenced this issue Nov 13, 2019
When go modules enabled user code is not intended be in GOROOT(/go) hence
placing source code in /src. Otherwise we hit with below error:

go: inconsistent vendoring in /go/src/github.com/intel/pmem-csi:
        go.mod requires github.com/intel/pmem-csi  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
make: *** [Makefile:70: pmem-csi-driver] Error 1

Ref: golang/go#34657

Jenkinsfile: Place the pmem-csi source out of GOPATH
avalluri added a commit to avalluri/pmem-CSI that referenced this issue Nov 14, 2019
When go modules enabled user code is not intended be in GOROOT(/go) hence
placing source code in /src. Otherwise we hit with below error:

go: inconsistent vendoring in /go/src/github.com/intel/pmem-csi:
        go.mod requires github.com/intel/pmem-csi  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
make: *** [Makefile:70: pmem-csi-driver] Error 1

Ref: golang/go#34657

Jenkinsfile: Place the pmem-csi source out of GOPATH
avalluri added a commit to avalluri/pmem-CSI that referenced this issue Nov 14, 2019
When go modules enabled user code is not intended be in GOROOT(/go) hence
placing source code in /src. Otherwise we hit with below error:

go: inconsistent vendoring in /go/src/github.com/intel/pmem-csi:
        go.mod requires github.com/intel/pmem-csi  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
make: *** [Makefile:70: pmem-csi-driver] Error 1

Ref: golang/go#34657

Jenkinsfile: Place the pmem-csi source out of GOPATH
pohly added a commit to pohly/pmem-CSI that referenced this issue Nov 15, 2019
When go modules enabled user code is not intended be in GOROOT(/go) hence
placing source code in /src. Otherwise we hit with below error:

go: inconsistent vendoring in /go/src/github.com/intel/pmem-csi:
        go.mod requires github.com/intel/pmem-csi  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
make: *** [Makefile:70: pmem-csi-driver] Error 1

Ref: golang/go#34657

Jenkinsfile: Place the pmem-csi source out of GOPATH
avalluri added a commit to avalluri/pmem-CSI that referenced this issue Nov 15, 2019
When go modules enabled user code is not intended be in GOROOT(/go) hence
placing source code in /src. Otherwise we hit with below error:

go: inconsistent vendoring in /go/src/github.com/intel/pmem-csi:
        go.mod requires github.com/intel/pmem-csi  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
make: *** [Makefile:70: pmem-csi-driver] Error 1

Ref: golang/go#34657

Jenkinsfile: Place the pmem-csi source out of GOPATH
avalluri added a commit to avalluri/pmem-CSI that referenced this issue Nov 15, 2019
When go modules enabled user code is not intended be in GOROOT(/go) hence
placing source code in /src. Otherwise we hit with below error:

go: inconsistent vendoring in /go/src/github.com/intel/pmem-csi:
        go.mod requires github.com/intel/pmem-csi  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
make: *** [Makefile:70: pmem-csi-driver] Error 1

Ref: golang/go#34657

Jenkinsfile: Place the pmem-csi source out of GOPATH
avalluri added a commit to avalluri/pmem-CSI that referenced this issue Nov 15, 2019
When go modules enabled user code is not intended be in GOROOT(/go) hence
placing source code in /src. Otherwise we hit with below error:

go: inconsistent vendoring in /go/src/github.com/intel/pmem-csi:
        go.mod requires github.com/intel/pmem-csi  but vendor/modules.txt does not include it.
        run 'go mod tidy; go mod vendor' to sync
make: *** [Makefile:70: pmem-csi-driver] Error 1

Ref: golang/go#34657

Jenkinsfile: Place the pmem-csi source out of GOPATH
hyangah added a commit to hyangah/pprof that referenced this issue Dec 5, 2019
AppVeyor sets the latest go stack in C:\go and that is GOROOT.
Cloning this repo under C:\go\src\.. directory confused go build
(as discussed in golang/go#34657). The fix in go is not yet
released. Thus this commit changes GOPATH to c:\gopath and clones
the repo under the directory.

Also, this commit removes the go get commands intended to pull in
dependencies. In modules mode, `go build` pulls in the required
dependencies.
aalexand added a commit to google/pprof that referenced this issue Dec 5, 2019
* Add go.mod/go.sum

* travis: update to test in modules mode and with go1.13

Remove go1.11 setup

* fix appveyor config

AppVeyor sets the latest go stack in C:\go and that is GOROOT.
Cloning this repo under C:\go\src\.. directory confused go build
(as discussed in golang/go#34657). The fix in go is not yet
released. Thus this commit changes GOPATH to c:\gopath and clones
the repo under the directory.

Also, this commit removes the go get commands intended to pull in
dependencies. In modules mode, `go build` pulls in the required
dependencies.
@L-maple

This comment has been minimized.

Copy link

@L-maple L-maple commented Dec 23, 2019

Ah, go env shows the problem:

set GOROOT=c:\go

GOROOT (in this case, c:\go) is where the Go standard library lives. User code is not intended to be placed there.

Yes, this tip has solved my problem!! Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.