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 build' on a module absolute path while cwd is in GOPATH builds in GOPATH mode #27612

Closed
natefinch opened this issue Sep 11, 2018 · 7 comments

Comments

@natefinch
Copy link
Contributor

@natefinch natefinch commented Sep 11, 2018

What did you do?

If I init a go module outside my gopath and then run go build from that directory, it works as expected.

If I run go build /absolute/dir/of/module but my current working directory is inside my gopath, go build will try to look up dependencies in my gopath (and fail if they're not there).

This seems wrong. if I give a path to the code, the path of the code should be what determines whether or not to use modules, no the current directory of where go build is run. Otherwise, I get different behavior for building the same code in the same place dependent on the CWD, which is extremely confusing and hard to debug.

System details

go version go1.11 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/finchnat/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/finchnat"
GOPROXY=""
GORACE=""
GOROOT="/Users/finchnat/sdk/go1.11"
GOTMPDIR=""
GOTOOLDIR="/Users/finchnat/sdk/go1.11/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
GOROOT/bin/go version: go version go1.11 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.11
uname -v: Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.13.6
BuildVersion:	17G65
lldb --version: lldb-902.0.79.7
  Swift-4.1
@myitcv
Copy link
Member

@myitcv myitcv commented Sep 11, 2018

Sounds like this is somewhat related to #26709?

@natefinch
Copy link
Contributor Author

@natefinch natefinch commented Sep 11, 2018

Yeah. Probably the same problem as stated at the end of that issue, though it's not described in that issue's main text.

@natefinch
Copy link
Contributor Author

@natefinch natefinch commented Sep 11, 2018

Addendum.... this came up as a problem because I would build go code outside my gopath, and the go tool downloaded the dependencies, but then I'd try to build the same code in the same location, but with the working directory inside gopath, and the go tool wouldn't be able to find the dependencies (because it was looking in gopath).

@andybons
Copy link
Member

@andybons andybons commented Sep 26, 2018

@bcmills bcmills changed the title cmd/go: running go build on a module absolute path while cwd is in gopath does the wrong thing cmd/go: 'go build' on a module absolute path while cwd is in GOPATH builds in GOPATH mode Sep 27, 2018
@bcmills
Copy link
Member

@bcmills bcmills commented Sep 27, 2018

I don't think see a viable alternative to the current behavior.
What would you expect to happen if you gave absolute paths to two different modules, or one path within GOPATH and one path outside?

@natefinch
Copy link
Contributor Author

@natefinch natefinch commented Sep 27, 2018

Building two things is not this issue. But -
if go build doesn't support building two different modules or a module and a gopath then it should error out in those situations.

However, if I run go build on exactly one thing, there's only possible correct behavior, and there not the behavior that occurs right now. I'm not sure where the confusion is with that.

@bcmills
Copy link
Member

@bcmills bcmills commented Jan 17, 2019

In the near future, you will always be in module mode by default. I can't justify the complexity of adding target-sensitive mode switching (and, in particular, of detecting mode-spanning arguments) when they would just be temporary anyway.

@bcmills bcmills closed this Jan 17, 2019
@golang golang locked and limited conversation to collaborators Jan 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants