/cc @adg @broady @campoy @ianlancetaylor @griesemer @robpike @rsc

I like it, but do we have any specific preference for "gocode" and not something like "gopath"?

How many people already use GOPATH=$HOME/gocode? It seems to me not many. That suggests it is the wrong default.

"gocode" will have search engine and other confusion with the popular tool github.com/nsf/gocode.

Do we have any information about what most people do?

I use GOPATH=$HOME/gopath myself.

Thumbs up here if you currently use GOPATH=$HOME

Thumbs up here if you currently use GOPATH=$HOME/gopath

Thumbs up here if you currently use GOPATH=$HOME/gocode

Should I do a twitter poll on @golang?

@campoy, sounds good. Probably better than inviting everybody to this bug.

How about $HOME/go (which is what I use).

See also : http://go-talks.appspot.com/github.com/freeformz/talks/20160712_gophercon/talk.slide#7

$HOME: 8.9%
$HOME/go: 50.6%
Other : 40.5%

I really wish I had split out more options for this one.

Voting started: https://twitter.com/golang/status/781189567437164544

On Wed, Sep 28, 2016, 10:51 AM Edward Muller notifications@github.com
wrote:

How about $HOME/go (which is what I use).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#17262 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACIkDJ83L5fXByqw-NEQ11JxKPGv_iQkks5quqkXgaJpZM4KI0I2
.

See also Column I here : https://docs.google.com/spreadsheets/d/1peTY_lq8rRW2zsKjwhd8iwiFZP5AZSrCvbCc07mPOWA/edit#gid=1525640201

@freeformz,

$HOME/go is conflicting with the path go source code (go.googlesource.com/go) is often checked out. It is bad that the community blessed this location as a default for GOPATH :( I worry if someone forgets to set their GOPATH and runs the go tool, it will mess their current development directory.

@rakyll to each their own, just wanted to indicate what I and many others use. go.googlesource.com/go is checked out in /usr/local/go.git on my system.

How many people already use GOPATH=$HOME/gocode? It seems to me not many. That suggests it is the wrong default.

For the record I use GOPATH=$HOME, but I felt that this would be too contentious and detract from the goal of this proposal which is to improve the experience for the new user.

@freeformz, I guess we don't have to care about the existing canonical paths that are outside of $HOME. The default for GOPATH is going to be in $HOME somewhere and the minimal requirement should be that it doesn't conflict with any critical existing path.

$HOME/gocode sounds alien to me but it could be a very good choice.

The point being, it matters less what the default is, just that there is one.

It does matter what the default is, because setting this default will essentially make it how everyone new to Go is working a few years from now.

The go command goes out of its way not to get confused when GOPATH=$GOROOT explicitly; I'm sure the same logic can be made to apply to am implicit setting as well. So I'm not too worried about smashing $HOME/go accidentally.

I still wonder if instead of a fixed default we should be auto-sniffing the current directory's parents to figure out where GOPATH is. This is what many source tools do these days (for example, every version control system), so it's a concept people would understand. And it doesn't force them to use one directory name or to have only one GOPATH workspace. But we might as well have that discussion on the original issue.

@rsc I'd love that default to be GOPATH=$HOME because that means $GOPATH/bin will be in their path (on most linux distributions at least, not sure about darwin).

$GOPATH=$HOME/go is also a good choice and those who have the source of the compiler checked out there will have already set GOPATH=something else so there is no chance of conflict.

To be clear, I wasn't trying to be flippant when I said

The point being, it matters less what the default is, just that there is one.

Rather trying to emphasise the goal of this proposal is to have the go tool use a default value for $GOPATH when one is not provided as this is a continual source of confusion and frustration for so many newcomers to the language.

I'm 👎 on auto sniffing because it fails a major use case, which is:

1. I've installed Go, I didn't actually read the Go installation docs, just followed what it said on the repo's README that said brew install go
2. I've run go get github.com/thething/theproject
3. Now I get an error about not setting $GOPATH. What is that? I just wanted to run this program that someone tweeted about!

A default value ofGOPATH=$HOME/go SGTM, assuming we decide on a default and not an auto-sniffing approach.

The go command goes out of its way not to get confused when GOPATH=$GOROOT explicitly; I'm sure the same logic can be made to apply to am implicit setting as well.

Sounds great.

not sure about darwin

Not on darwin.

If this is for newcomers, I would advise against GOPATH=$HOME as that would create three directories in their home directory versus just one. I'm not keen on software that pollutes my home dir beyond necessary.

@mvdan I understand and your reaction was why I did not propose GOPATH=$HOME.

If I personally want to set my GOPATH to $HOME, then that option would remain available to me, and I would have to make no changes should this proposal be accepted for Go 1.8.

@davecheney

default to a value of GOPATH=$HOME/gocode

There is no default HOME variable on Windows. What do you propose to do on Windows?

I'd love that default to be GOPATH=$HOME because that means $GOPATH/bin will be in their path

I am always worried about having $GOPATH/bin in my PATH. go get installs other people's programs there. Do we really want new Go user installing random programs from the Internet somewhere in their PATH?

Alex

I'm not an experienced windows user, but I assume there is some notion of a base path where documents and settings are stored. For the purpose of this discussion assume that I'm talking about that path in the context of windows users.

If no such path exists, assume C:/gocode.

Wrt to my comment on GOPATH=$HOME, while this is and will continue to be my personal preference, I recognise that this is a contentious option for a default value and as such did not suggest it as the proposed value.

My proposed behavior for this change:

Environment variables

• If GOPATH is set the tools behaves as it always has
• Otherwise, we check the HOME (home for plan9, USERPROFILE for windows) environment variable.
  • If that env variable is not set then GOPATH will not be set either: this means that "go get" will fail with cannot download, $GOPATH not set.

> unset GOPATH
> unset HOME
> go env GOPATH

• Otherwise GOPATH will be set as $HOME/go ($home/go, %USERPROFILE%\go).

> unset GOPATH
> go env GOPATH
/Users/campoy/go

GOPATH creation

Currently if $GOPATH doesn't exist it is created when we execute go get import/path. This will not change.

The only change is that if $GOPATH is not set in the user environment (i.e. echo $GOPATH displays no value) an extra check is performed to make sure the default value is acceptable:

• if GOPATH is not set and no default value was created: the command will fail

> unset GOPATH
> unset HOME
> go get github.com/golang/example/hello
package github.com/golang/example/hello: cannot download, $GOPATH not set. For more details see: 'go help gopath'
👎

• if the default $GOPATH doesn't exist a warning will be displayed explaining that the directory was created, pointing to go help gopath for more info.

> unset GOPATH
> go get github.com/golang/example/hello
warning: GOPATH is not set, creating directory /Users/campoy/go. See 'go help gopath' for more information
👍

• if the default $GOPATH exists:
  • and it is not a directory: the command will fail (as it did before)

> unset GOPATH
> touch ~/go
> go get github.com/golang/example/hello
package github.com/golang/example/hello: can't use GOPATH at /Users/campoy/go: it is not a directory
👎

• and it is either an empty directory or a directory that has a subdirectory named src the command will succeed (no warnings)

> unset GOPATH
> mkdir ~/go
> go get github.com/golang/example/hello
👍

> unset GOPATH
> mkdir -p ~/go/src
> touch ~/go/others
> go get github.com/golang/example/hello
👍

• and it is a non empty directory without a subdirectory named src the command will fail

> unset GOPATH
> mkdir ~/go
> touch ~/go/others
> go get github.com/golang/example/hello
package github.com/golang/example/hello: can't use GOPATH at /Users/campoy/go: it is not empty, and no 'src' was found
👎

So only a new warning is included whenever a directory is created using a default GOPATH.

@campoy the behavior proposal looks great.

But again as an advanced user I want to know how many of us seriously use $HOME/go as the GOPATH on a daily basis? I was even thinking maybe there should be a go command to set the GOPATH similar to starting a virtual env on a python work directory.

Since I work on multiple projects I usually do something like this:

$ cd foo-app
$ export GOPATH=$(pwd)

# switching to another app
$ cd ../foobar-app
$ export GOPATH=$(pwd)

@jinmatt
This change only modifies the behavior for unset GOPATH, that's the scope of the change.
The community already reached an agreement on $HOME/go.

If you don't like $HOME/go, just set GOPATH to whatever value you prefer (e.g. $HOME in my case).

Thank you for the design sketch.

1. Since we've now established that GOPATH is only going to be created during 'go get', let's only print messages if the -v flag is given, consistent with the rest of 'go get -v' behavior.

2. If the directory is created, the message should be at most

   created GOPATH=/users/campoy/go; see 'go help gopath'

It's not a warning: warnings are bad. On the other hand if the create fails then you might well want to print

go: creating GOPATH=/users/campoy/go: %v

Both of those messages can be printed regardless of whether GOPATH is inferred or set explicitly.

1. The heuristics about empty directory and having a src subdirectory are too complex. Worse, they are addressing hypothetical problems, and hypotheticals are very difficult to design for. Better to have simpler, more predictable behavior. To start, I think it makes sense not to have any rules, until there are concrete examples of actual problems. There will be time for people to report problems during the betas and release candidates. Let's just set GOPATH=$HOME/go (provided $HOME is set).

Edit: pretend that Github markdown didn't completely screw this up.

@campoy Regarding the src/ directory, what is the current behaviour of go get when a GOPATH is set but no src directory exists? Is there a good reason to not also create it?

It just seems simpler to explain if $HOME/go/src gets created on the first go get (or $GOPATH/src if that environment variable is set)

Today, when GOPATH is set, the necessary directories are created, unconditionally, as needed.

CL https://golang.org/cl/33356 mentions this issue.

CL https://golang.org/cl/33730 mentions this issue.