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: document module-mode behavior of multi-element GOPATHs #29005

Open
mvdan opened this issue Nov 29, 2018 · 10 comments
Open

cmd/go: document module-mode behavior of multi-element GOPATHs #29005

mvdan opened this issue Nov 29, 2018 · 10 comments
Labels
Documentation help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Backlog

Comments

@mvdan
Copy link
Member

mvdan commented Nov 29, 2018 

go version devel +311d87dbeb Thu Nov 29 08:30:13 2018 +0000 linux/amd64

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/mvdan/go/cache"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/mvdan/go/land:/home/mvdan/go"
GOPROXY=""
GORACE=""
GOROOT="/home/mvdan/tip"
GOTMPDIR=""
GOTOOLDIR="/home/mvdan/tip/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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-build190148469=/tmp/go-build -gno-record-gcc-switches"

In my case, mvdan.cc/sh/cmd/gosh is a main package inside the second GOPATH directory. It's also a module, so it can be built in either mode.

$ cd ~/go/src/mvdan.cc/sh/cmd/gosh
$ GO111MODULE=on go list -f {{.Target}}
/home/mvdan/go/land/bin/gosh
$ GO111MODULE=off go list -f {{.Target}}
/home/mvdan/go/bin/gosh

I understand why the GOPATH build puts the binary where it does - that's the old and documented logic.

And I too sort of understand why the module build goes into the first GOPATH entry - it's not building the package within any one GOPATH, so it just picks the first.

However, this can be very confusing. In my case, I ended up with two binaries, and because of PATH I was always running the older. The only mention is brief, under go help modules:

and installed commands (in GOPATH/bin, unless GOBIN is set)

I realise now that my fix should be to either set up a global GOBIN, or to stop using a multi-element GOPATH. I still think the documentation could be clearer, though. I think we should discourage the use of a multi-element GOPATH with no GOBIN in the modules world, because of the tricky scenario above.

/cc @bcmills @myitcv @rogpeppe
@mvdan mvdan added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Nov 29, 2018
@bcmills
Copy link
Contributor

bcmills commented Nov 29, 2018

I think we should discourage the use of a multi-element GOPATH with no GOBIN in the modules world, because of the tricky scenario above.

Having a multi-element GOPATH in the first place puts you firmly in the power-user category. I'm not sure that we need to warn about this because I'm skeptical that many users are in that situation to begin with...

@mvdan
Copy link
Member Author

mvdan commented Nov 29, 2018

Agreed; I wonder if anyone else would even run into this issue. But still, it had me confused for a good twenty minutes, because I wasn't realising that I had two separate binaries for the same main package.

Perhaps a better generic warning would be on the use of a multi-element GOPATH. That is, "if you want to use this, you likely want to set GOBIN too". Or even "this likely doesn't make sense if you're going to work with modules".

@rogpeppe
Copy link
Contributor

Having a multi-element GOPATH in the first place puts you firmly in the power-user category. I'm not sure that we need to warn about this because I'm skeptical that many users are in that situation to begin with...

I think that at least the "GOPATH and Modules" section in go help gopath should mention the expected behaviour when GOPATH has multiple elements (it always uses the first element for everything, presumably).

@bcmills bcmills changed the title cmd/go: module-aware 'go install' with a multi-element GOPATH can be confusing cmd/go: document module-mode behavior of multi-element GOPATHs Jan 17, 2019
@bcmills bcmills added the NeedsFix The path to resolution is known, but the work has not been done. label Jan 17, 2019
@bcmills bcmills added this to the Go1.13 milestone Jan 17, 2019
@gopherbot gopherbot removed the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Jan 17, 2019
@bcmills bcmills mentioned this issue Jan 18, 2019
Open
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@perillo
Copy link
Contributor

perillo commented Feb 14, 2020

I also use a multi-element GOPATH, set to /home/manlio/.local/lib/go:/home/manlio/src/go and I have explicitly set GOBIN.

However I find it strange to have a GOPATH entry inside the other GOPATH entry. It should probably be disallowed. What is the reason for this choice?

@mvdan
Copy link
Member Author

mvdan commented Feb 14, 2020

What is the reason for this choice?

The choice was arbitrary, and it doesn't really matter anymore :) I dropped that configuration over a year ago when I fully switched all my projects to modules.

@perillo
Copy link
Contributor

perillo commented Feb 14, 2020

I still have the multi-element GOPATH. Originally I used it to keep separate external packages and my packages, but now I'm still using it since it is nice to have the module cache in ~/.local.

@bcmills
Copy link
Contributor

bcmills commented Feb 14, 2020

@perillo, note that it will likely be possible to configure the module cache location without reference to GOPATH in Go 1.15 (see #34527).

@perillo
Copy link
Contributor

perillo commented Feb 14, 2020

@bcmills, thanks. But what will happen to GOPATH? I hope it will not be removed since all my modules are inside GOPATH, with the property that

filepath.Join($GOPATH, module.Path) == module.Dir

I'm starting to call modules with this property local modules and I'm writing some tools to make it easy (as with gopath mode) to work with them.

@bcmills
Copy link
Contributor

bcmills commented Feb 14, 2020

We're still figuring out the future of GOPATH, but nothing will fundamentally stop you from continuing to structure your local directory layout that way going forward.

(Just be aware that modules, unlike GOPATH directories, can interleave: package example.com/foo/bar may be provided by module example.com, even if package example.com/foo is in its own distinct module in the middle.)

@eddycjy
Copy link

eddycjy commented Feb 20, 2021

@bcmills I recently read the latest official blog post about its plan to remove GOPATH in Go1.17. Is this too unreasonable for a historical project?

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Documentation help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
8 participants
@rogpeppe @rsc @andybons @mvdan @bcmills @perillo @gopherbot @eddycjy