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: '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
Closed

cmd/go: 'go build' on a module absolute path while cwd is in GOPATH builds in GOPATH mode #27612

natefinch opened this issue Sep 11, 2018 · 7 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@natefinch
Copy link
Contributor

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 commented Sep 11, 2018

Sounds like this is somewhat related to #26709?

@natefinch
Copy link
Contributor Author

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

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 andybons added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. modules labels Sep 26, 2018
@andybons andybons added this to the Unplanned milestone Sep 26, 2018
@andybons
Copy link
Member

@bcmills @rsc

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

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

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
Contributor

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 as completed 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.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
5 participants
@andybons @natefinch @myitcv @bcmills @gopherbot