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: look only at dependencies in use in 'go run' #31057

Closed
josharian opened this issue Mar 26, 2019 · 6 comments

Comments

Projects
None yet
3 participants
@josharian
Copy link
Contributor

commented Mar 26, 2019

With no network access:

$ cd $GOROOT/src/cmd/compile/internal/gc
$ go run mkbuiltin.go
go: golang.org/x/sys@v0.0.0-20190322080309-f49334f85ddc: unrecognized import path "golang.org/x/sys" (https fetch: Get https://golang.org/x/sys?go-get=1: dial tcp: lookup golang.org: no such host)
go: golang.org/x/crypto@v0.0.0-20190325154230-a5d413f7728c: unrecognized import path "golang.org/x/crypto" (https fetch: Get https://golang.org/x/crypto?go-get=1: dial tcp: lookup golang.org: no such host)
go: golang.org/x/tools@v0.0.0-20190325223049-1d95b17f1b04: unrecognized import path "golang.org/x/tools" (https fetch: Get https://golang.org/x/tools?go-get=1: dial tcp: lookup golang.org: no such host)
go: error loading module requirements

But the imports used by mkbuiltin.go are 100% standard library with no dependency that I see on those three repos.

It looks to my untrained eye like the cmd/compile/internal/gc package depends on those repos, but not mkbuiltin.go. Assuming that that is accurate, and given that go run x.go is effectively independent of the location of x.go on disk, it seems to me that my go run command should have succeeded.

cc @bcmills @jayconrod

Apologies if this is a duplicate; I'm having a hard time keeping track of the various go modules issues.

@josharian josharian added the GoCommand label Mar 26, 2019

@josharian josharian added this to the Go1.13 milestone Mar 26, 2019

@robpike

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2019

Does go build with this case have the same problem? I've been seeing surprising output from go build lately.

@josharian

This comment has been minimized.

Copy link
Contributor Author

commented Mar 27, 2019

I’m not sure. I still haven’t fully wrapped my head around modules, but I have noticed that cmd/go needs a surprising amount of network access. (I’m used to basically everything working without the internet, and am disconcerted by the notion that I do not understand enough to be able to plan for an airplane trip, much less not have to plan at all.) But I am working under the assumption that all of the foregoing is my problem.

@robpike

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2019

It might not be just your problem. I see much network access (and slowness) that I cannot explain.

@bcmills bcmills added the modules label Mar 27, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented Mar 27, 2019

Could you attach the output of go version and go env from within that working directory?

If you're using go run with a 1.12 compiler, then it won't have the special-case vendor logic required to avoid fetching the dependencies listed for the cmd module.

I've been testing these sorts of issues using GOPATH=$(mktemp -d) GOPROXY=off PATH=~/minbin, where ~/minbin does not contain any binaries that (to my knowledge) provide network access. (Setting GOPATH to an empty directory and GOPROXY=off ensures that the go command does not have access to a cached or proxied copy of those modules.)

For the command line you provided, a go build from head does not seem to fetch anything.

~/go/src/cmd/compile/internal/gc$ go version
go version devel +591193b01f Wed Mar 27 21:04:34 2019 +0000 linux/amd64

~/go/src/cmd/compile/internal/gc$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/usr/local/google/home/bcmills/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/usr/local/google/home/bcmills"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/google/home/bcmills/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/google/home/bcmills/go/pkg/tool/linux_amd64"
GCCGO="/usr/local/google/home/bcmills/bin/gccgo"
CC="gcc"
CXX="c++"
CGO_ENABLED="1"
GOMOD="/usr/local/google/home/bcmills/go/src/cmd/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-build587017954=/tmp/go-build -gno-record-gcc-switches"

~/go/src/cmd/compile/internal/gc$ GOPATH=$(mktemp -d) GOPROXY=off PATH=~/minbin go run mkbuiltin.go

~/go/src/cmd/compile/internal/gc$ ls ~/minbin
ar  as  cat  clang  echo  env  gcc  go  ld  pwd  uname  whoami

~/go/src/cmd/compile/internal/gc$

@bcmills

This comment has been minimized.

Copy link
Member

commented Mar 27, 2019

@josharian

This comment has been minimized.

Copy link
Contributor Author

commented Apr 1, 2019

Ahhh. I was indeed using go run with a 1.12 compiler.

Thanks for the heads up about how to narrow down and reproduce these.

@josharian josharian closed this Apr 1, 2019

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