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

cmd/go: vendor directory in src/cmd breaks build in module mode #26924

Closed
rsc opened this issue Aug 10, 2018 · 8 comments
Closed

cmd/go: vendor directory in src/cmd breaks build in module mode #26924

rsc opened this issue Aug 10, 2018 · 8 comments
Labels
FrozenDueToAge GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.13

Comments

@rsc
Copy link
Contributor

rsc commented Aug 10, 2018

GOROOT/src/cmd's use of a nested vendor directory makes it not work with module mode.
We'll have to fix that at some point.
@rsc rsc added this to the Go1.12 milestone Aug 10, 2018
@myitcv
Copy link
Member

myitcv commented Aug 10, 2018

Does this also apply to the top-level src/vendor directory?

export GOPATH=$(mktemp -d)
cd $(mktemp -d)
mkdir hello
cd hello
go mod init example.com/hello
go test vendor/golang_org/x/net/http/httpproxy

results in:

# vendor/golang_org/x/net/http/httpproxy_test [vendor/golang_org/x/net/http/httpproxy.test]
/home/myitcv/gos/src/vendor/golang_org/x/net/http/httpproxy/proxy_test.go:304:6: undefined: httpproxy.ExportUseProxy
/home/myitcv/gos/src/vendor/golang_org/x/net/http/httpproxy/proxy_test.go:314:8: undefined: httpproxy.ExportUseProxy
/home/myitcv/gos/src/vendor/golang_org/x/net/http/httpproxy/proxy_test.go:325:6: undefined: httpproxy.ExportUseProxy
FAIL    vendor/golang_org/x/net/http/httpproxy [build failed]

Or would you prefer this as a separate issue?

@rsc
Copy link
Contributor Author

rsc commented Aug 18, 2018

It's basically the same. It can be this issue too.

@bcmills
Copy link
Contributor

bcmills commented Sep 6, 2018

Hmm, this might be the same underlying cause as the failure @cespare observed in #26996 (comment).

@myitcv myitcv mentioned this issue Sep 7, 2018
Closed
@bcmills bcmills modified the milestones: Go1.12, Go1.13 Nov 15, 2018
@bcmills bcmills self-assigned this Nov 15, 2018
@bcmills bcmills mentioned this issue Nov 19, 2018
Closed
@heschi heschi mentioned this issue Nov 21, 2018
Closed
@bcmills bcmills added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. GoCommand cmd/go labels Dec 12, 2018
@bcmills bcmills mentioned this issue Jan 24, 2019
Closed
@bcmills bcmills changed the title cmd/go: module mode does not let ... match GOROOT/src/cmd/* cmd/go: vendor directory in src/cmd breaks build in module mode Feb 14, 2019
This was referenced Feb 14, 2019
Closed
Open
@gopherbot
Copy link

Change https://golang.org/cl/162989 mentions this issue: go/analysis: allow overriding V flag without code patches

gopherbot pushed a commit to golang/tools that referenced this issue Feb 20, 2019
go/analysis: allow overriding V flag without code patches
e8c45e0 
In CL 149609, a file was added to
src/cmd/vendor/golang.org/x/tools/go/analysis/internal/analysisflags/patch.go
to override the behavior of the V flag for cmd/vet.

That modification causes the behavior of cmd/vet to change when a
pristine copy of x/tools is vendored in, and module-mode vendoring
will only support pristine copies (see golang/go#30240).

Instead, allow cmd/vet to override the V flag by defining its own V
flag before it invokes unitchecker.Main.

Tested manually (by patching into cmd/vendor).

Updates golang/go#30240
Updates golang/go#30241
Updates golang/go#26924
Updates golang/go#30228

Change-Id: I10e4523e1f4ede94fbfc745012dadeefef48e927
Reviewed-on: https://go-review.googlesource.com/c/162989
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
@gopherbot
Copy link

Change https://golang.org/cl/162990 mentions this issue: windows: gofmt -w windows/security_windows.go

gopherbot pushed a commit to golang/sys that referenced this issue Feb 20, 2019
windows: gofmt -w windows/security_windows.go
629670e 
x/sys/unix is vendored into the standard library, and the commit hook
for the standard library requires files to be gofmt-clean.

Updates golang/go#26924

Change-Id: I22a994062bcdbebe8a1fe1ae0ed4606837f03079
Reviewed-on: https://go-review.googlesource.com/c/162990
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@gopherbot
Copy link

Change https://golang.org/cl/163520 mentions this issue: cmd/go: expand tests for standard-library vendoring in GOPATH mode

gopherbot pushed a commit that referenced this issue Feb 27, 2019
cmd/go: expand tests for standard-library vendoring in GOPATH mode
2c86713 
This should help to catch any regressions in the course of implementing #26924.

Updates #26924

Change-Id: Ide28a9aa0235867e0ce72f855fbed51c50e2c2f2
Reviewed-on: https://go-review.googlesource.com/c/163520
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
@gopherbot
Copy link

Change https://golang.org/cl/164621 mentions this issue: cmd/go: resolve non-standard imports from within GOROOT/src using vendor directories

@gopherbot
Copy link

Change https://golang.org/cl/164625 mentions this issue: go/internal/srcimporter: set -mod=vendor before running tests

gopherbot pushed a commit that referenced this issue Mar 1, 2019
go/internal/srcimporter: set -mod=vendor before running tests
7c388cc 
Otherwise, if the working directory is inside a standard-library
module, the test may try to fetch module contents from GOPROXY or
upstream.

Updates #26924
Updates #30228
Updates #30241

Change-Id: I4cb9a07721bd808fd094f7ed55a74cf7bce9cd6f
Reviewed-on: https://go-review.googlesource.com/c/164625
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
@bcmills bcmills mentioned this issue Apr 10, 2019
Closed
@golang golang locked and limited conversation to collaborators Mar 10, 2020
@rsc rsc unassigned bcmills Jun 23, 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 modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.13
Development

No branches or pull requests
5 participants
@rsc @agnivade @myitcv @bcmills @gopherbot