cmd/go: 'inconsistent vendoring' error when a user module is located within GOROOT/src #34657

awnumar · 2019-10-02T11:58:18Z

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

The text was updated successfully, but these errors were encountered:

andybons · 2019-10-02T14:57:11Z

@bcmills @jayconrod

bcmills · 2019-10-02T15:23:41Z

@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 · 2019-10-02T15:26:13Z

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 · 2019-10-02T15:27:13Z

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 · 2019-10-02T15:29:14Z

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

awnumar · 2019-10-02T18:33:22Z

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

bcmills · 2019-10-02T18:48:57Z

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

golang/go#34657

awnumar · 2019-10-04T11:28:23Z

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

bcmills · 2019-10-09T18:42:40Z

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.

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

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.

* 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 · 2019-12-23T08:07:29Z

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!

digikin · 2020-03-01T04:10:00Z

In windows there are two go folders generated.
C:\Go and C:\Users\XXX\go
To fix this issue you need to place all of your projects under the users golang folder:
C:\Users\XXX\go\src\github.com\XXXX

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

andybons added modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Oct 2, 2019

andybons added this to the Unplanned milestone Oct 2, 2019

bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Oct 2, 2019

bcmills removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Oct 2, 2019

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 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 added a commit to awnumar/memguard that referenced this issue Oct 4, 2019

patch: move working directory to separate location

0adae84

golang/go#34657

bcmills mentioned this issue Oct 7, 2019

Some random package broke all my go programs. #34731

Closed

bcmills closed this as completed Oct 9, 2019

bcmills modified the milestones: Unplanned, Go1.14 Oct 9, 2019

bcmills mentioned this issue Oct 10, 2019

Inconsistent Vendoring, Go list failed #34818

Closed

avalluri mentioned this issue Nov 13, 2019

Go 1.13 + Moving to go modules intel/pmem-csi#461

Merged

saiprasannasastry mentioned this issue Feb 25, 2020

inconsistent vendoring infobloxopen/terraform-provider-infoblox#59

Closed

stamblerre mentioned this issue Mar 7, 2020

x/tools/gopls: inconsistent vendoring issue #37734

Closed

MilhouseVH mentioned this issue Apr 28, 2020

buildsystem: fix go-based packages LibreELEC/LibreELEC.tv#4357

Merged

evanmoses-okta mentioned this issue May 15, 2020

x/tools/gopls: inconsistent vendoring issue breaks gopls #39100

Closed

richardlehane mentioned this issue Aug 27, 2020

Question on how to get comdump to run richardlehane/comdump#1

Closed

golang locked and limited conversation to collaborators Mar 1, 2021

gopherbot added the FrozenDueToAge label Mar 1, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/go: 'inconsistent vendoring' error when a user module is located within GOROOT/src #34657

cmd/go: 'inconsistent vendoring' error when a user module is located within GOROOT/src #34657

awnumar commented Oct 2, 2019

andybons commented Oct 2, 2019

bcmills commented Oct 2, 2019

bcmills commented Oct 2, 2019

bcmills commented Oct 2, 2019 •

edited

bcmills commented Oct 2, 2019

awnumar commented Oct 2, 2019

bcmills commented Oct 2, 2019

awnumar commented Oct 4, 2019

bcmills commented Oct 9, 2019

L-maple commented Dec 23, 2019

digikin commented Mar 1, 2020 •

edited

cmd/go: 'inconsistent vendoring' error when a user module is located within GOROOT/src #34657

cmd/go: 'inconsistent vendoring' error when a user module is located within GOROOT/src #34657

Comments

awnumar commented Oct 2, 2019

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

andybons commented Oct 2, 2019

bcmills commented Oct 2, 2019

bcmills commented Oct 2, 2019

bcmills commented Oct 2, 2019 • edited

bcmills commented Oct 2, 2019

awnumar commented Oct 2, 2019

bcmills commented Oct 2, 2019

awnumar commented Oct 4, 2019

bcmills commented Oct 9, 2019

L-maple commented Dec 23, 2019

digikin commented Mar 1, 2020 • edited

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

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

bcmills commented Oct 2, 2019 •

edited

digikin commented Mar 1, 2020 •

edited