Go: cmd/go: assume GOPATH=$HOME/go if not set

/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 [email protected]
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
https://github.com/golang/go/issues/17262#issuecomment-250244110, 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.

Auto-detection is fraught with danger. I started prototyping this a while back, but it added significant complexity both to the go tool and the user experience.

I'm not in the loop of what's been happening with the package management working group, but I can imagine a not-too-distant future where GOPATH is eliminated entirely.

That said, even if GOPATH does disappear some time in the near future, there may still be value in setting a default. If we do think GOPATH is likely to disappear, it doesn't matter too much what we set it to.

From what I read above, there is some consensus that:

1. As a default, GOPATH=$HOME is too invasive.
2. The default should include the string go somewhere (likely as a prefix).

I'm not worried about GOPATH being a clone of the main go repo (i.e., GOPATH == GOROOT). People checking out the go repo are likely to have a GOPATH set. The go tool would detect the conflict anyway, as it does today.

With that in mind, the most succinct default would be $HOME/go, which I think is quite reasonable.

I assume there is some notion of a base path where documents and settings are stored.

I don't know of such thing. Perhaps other Windows users will comment here.

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

You want C:gocode instead.
Putting things in the root of C:\ does not sounds right to me. Would you recommend GOPATH to be set to /gocode on Linux?
But, given that Windows installer already installs Go into C:go, C:gocode for GOPATH is at least consistent.

Alex

But, given that Windows installer already installs Go into C:go, C:gocode for GOPATH is at least consistent.

GOPATH should not be provided for each users? To be the same as UNIX, %USERPROFILE%\gocode, I guess.

Go+ poll at https://goo.gl/xAsgEj

after i used for a long time something like $HOME/go-programs i switched GOPATH to $HOME. so,now i have the following structure:

$HOME/bin
$HOME/pkg
$HOME/src/
$HOME/src/github.com/user/some_github_project
$HOME/src/some_project

this structure is more generic and also can be used for using with other languages or projects and with github. for example i have $HOME/src/talks (read it home/sources/talks for markdown files) or other projects in some languages (like $HOME/src/github.com/user/html) but also sources and i have one place for many projects sources with or without github correspondence.

bin or pkg can be considered messy but i think is not so annoying. is more messy to have many source folder for people who use multiple languages.

so, from my point of view the best GOPATH place is $HOME.

I'm using $HOME/gocode as my GOPATH.
I'm against $HOME/go since sometimes you don't have the root privilege and you need to install Go under your home directory. In such case, I think $HOME/go would be the best for GOROOT.
So we should use something different from $HOME/go as GOPATH.

@hnakamur Back when I installed Go manually (now using Ubuntu Make), I put it in $HOME/bin/go-${go_version} (with a symlink from $HOME/bin/go to $HOME/bin/go-${version}/bin/go, so I didn't have to edit my $PATH)

@tbroyer It's niche. I guess most of users doen't want extra configuration or settings. In my opinion, ~/bin is used to put own script or binaries already (like me). And I think ~/bin (~/src, ~/pkg) make bit's difficult to remove go binaries.

I use $HOME for my GOPATH.
Why auto set GOPATH, why not raise warning with good info how to set it if GOPATH not exists ?

Why auto set GOPATH, why not raise warning with good info how to set it if GOPATH not exists ?

The problem isn't that people don't know how to set an environment variable (for the most part), it's that even if you do it feels poor to have to jump through hoops to get started using Go. Being able to use Go out of the box with sane defaults as soon as it's installed makes the experience as seamless as possible, and means more people are likely to actually try Go after downloading it, instead of hitting a roadblock, losing their momentum, and deciding it's not worth messing with.

I tend to agree with Chris and Andrew: if there's going to be a default GOPATH, it should be just $HOME/go, not gopath or gocode. _Most_ users do not have a Go distribution checked out there (and everyone who does today already sets GOPATH, so this won't bother them). The default needs to make sense for new users, not advanced ones, and for most users $HOME/go makes a lot of sense.

Jaana raised a concern about the go command getting confused if $HOME/go happens to be a Go distribution, but the go command already checks for accidental GOPATH=$GOROOT. It's easy to check if that's true when GOPATH is set implicitly as well. In fact it would also be easy to augment the check to look for, say, $HOME/go/src/cmd/go/alldocs.go, to avoid confusion even when GOROOT!=$HOME/go but $HOME/go does contain a Go distribution.

$HOME/go is not a good option for GOPATH. let's make a simple exercise of behaviour... new users can easy consider the default like a best practice. let say i'm a new user, why should i consider the defaults a bad thing? more than that the easiest (and the best?) method to install golang is by unpack in $HOME because with this method the compiler is always at the last version and need not root rights so you can easy suppose that many users will have go compiler in $HOME/go. why should i move the compiler in /usr/local when i can simply didn't?
more than that they can make projects and can clone projects in this folder. so, they will have a messy folder and with a little careless they can easy delete their project folder with a new golang reinstallation.
also, windows users have c:go by default.

I like $HOME/gopath. It says what it is.
The first result on Google for "gopath" is the right page.

If a default is adopted, could a func GOPATH() string function be added to runtime? Right now one can use os.Getenv(), but with a default it won't be so simple.

@btracey, GOPATH is a list, not a single value. Use filepath.SplitList. Also, GOPATH isn't a function of the runtime. It only concerns cmd/go.

For backward compatibility we'd probably need to set GOPATH in the process'
environment if none is set.

On 30 September 2016 at 08:10, Brendan Tracey [email protected]
wrote:

If a default is adopted, could a func GOPATH() string function be added
to runtime? Right now one can use os.Getenv(), but with a default it
won't be so simple.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17262#issuecomment-250605418, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIDilc6cjWl0r3-V-6FWruHIiYA_X4nJks5qvDc5gaJpZM4KI0I2
.

You're right @bradfitz. The solution proposed by @adg would meet all of my uses.

This is an interesting wrinkle. I can see this failing currently when no
GOPATH is set, but also when GOPATH contains multiple values, and then
there is case where the application is built on one machine and deployed on
another.

I don't want to dismiss this usage of GOPATH, I understand the pain of
being able to locate support files for your application, but I would like
to understand how widespread this usage is, and how the current
implementations deal with the issues I highlighted above.

On Fri, 30 Sep 2016, 08:35 Brendan Tracey [email protected] wrote:

You're right @bradfitz https://github.com/bradfitz. The solution
proposed by @adg https://github.com/adg would meet all of my uses.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17262#issuecomment-250611813, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA_e53SwZ7Zf_rWCcbZTyPEmXXhUTks5qvD1JgaJpZM4KI0I2
.

My usage is not the normal one. I do scientific research, and I have found it very effective to not just have gopath/src and gopath/bin, but also gopath/data and gopath/results. This makes it easy to copy the source files over to a new system without also having to copy the (gigabytes of) result files. The new system (say a cluster) generates new results files, and I can copy those results to a central location. It's really easy to then say gopath = os.Getenv("GOPATH"), and save a file to something like filepath.Join(gopath, "results", "projectname", result.json).

Thank you. To be clear I did not mean to imply your usage was incorrect or
wrong, I just wanted to understand this usage of GOPATH wrt to the
constraints I highlighted.

On Fri, 30 Sep 2016, 09:09 Brendan Tracey [email protected] wrote:

My usage is not the normal one. I do scientific research, and I have found
it very effective to not just have gopath/src and gopath/bin, but also
gopath/data and gopath/results. This makes it easy to copy the source
files over to a new system without also having to copy the (gigabytes of)
result files. The new system (say a cluster) generates new results files,
and I can copy those results to a central location. It's really easy to
then say gopath = os.Getenv("GOPATH"), and save a file to something like filepath.Join(gopath,
"results", "projectname", result.json).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17262#issuecomment-250617618, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA_CKox90AQMMAxOs9wEL2ffY0S0zks5qvEUPgaJpZM4KI0I2
.

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

@davecheney no offense taken, just wanted to provide enough context to be useful.

Let's please leave the use of GOPATH to find support files out of this discussion.

(GOPATH is meant to be a compile-time setting, not a run-time one. I know that people blur these sometimes and use GOPATH to find associated files at run-time, but I don't think we should encourage that or make it easier to do. We need a better story for support files in general, but that should be a separate issue.)

Related to finding associated files at run-time: #12773

Sorry to pollute the discussion once more @rsc, but @randall77 , #12773 is more difficult to use then just working around this issue directly. Specific code that needs a file (or to save a file) can move around a lot, and I want a fixed place for inputs/outputs to live independent of (and separate from) refactoring.

This issue is about a possible default value of GOPATH. It is _not_ about alternate uses of GOPATH.

If the target users for this change is only those that just wanted to
install a new program written in Go, and not those that actually want to
write Go, then what about we make go get cloning in a per-user directory in
$TMPDIR, and leave the binary at $PWD if $GOPATH is not set? (Obviously
this only makes sense for go get import.path/for/a/command, if it's not a
command, go get should fail without $GOPATH being set)

For the outsider, this makes much sense, just like wget a file.

Once the user wants to start writing Go code, they should learn how to set
GOPATH properly.

I'm against $HOME/go since sometimes you don't have the root privilege and you need to install Go under your home directory. In such case, I think $HOME/go would be the best for GOROOT.

If you are on a Linux system, I would argue that the best place for $GOROOT might be in $HOME/.local/opt/go, not $HOME/go, depending on how you interpret the purpose of $HOME/.local, as only $HOME/.local/share (appearing to mirror /usr/local/share) is defined in the XDG Base directory spec: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html.

One could also argue that the best default for GOPATH / GOBIN (on Linux) should be:
GOPATH=$XDG_DATA_HOME/go, or $HOME/.local/share/go
GOBIN=$HOME/.local/bin

However that's probably not the easiest to understand for new users? And it would also leave it unclear what's the best approach on Windows. $HOME/go and $USERPROFILE/go does seem pragmatic.

Please, _please_ let's not let this thread turn into a discussion of canonical Linux path names and storage locations. It is not productive, and I feel this discussion has already strayed pretty far from Dave Cheney's originally post.

I'm also not sure the actual absolute location matters that much, I think all this thread really needs to decide is "do we want a default Gopath?" (sounds like that's a more-or-less overwhelming yes) and "should it be shared systemwide, or local to the user" (so far most discussion has been about local). After that, whomever implements can pick $HOME/gocode or $HOME/go or /usr/share/go/ or whatever they desire that seems reasonable to whomever reviews the PR, and things will probably continue to be pretty okay.

I think a systemwide GOPATH is a non-starter because of permissions issues.

​

The system wide path is, for better or for worse, GOROOT, which distros
like debian are using to install "system wide" packages, for better or for
worse.

A system wide GOPATH is out of scope of this proposal, this proposal
recommends a path derived from value of the logged in user.

On Tue, 4 Oct 2016, 08:52 Andrew Gerrand [email protected] wrote:

I think a systemwide GOPATH is a non-starter because of permissions issues.

​

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17262#issuecomment-251238251, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA2kwyq0Iuidk0ygsGzqVKGLkKBR9ks5qwXkDgaJpZM4KI0I2
.

Please, please let's not let this thread turn into a discussion of canonical Linux path names and storage locations. It is not productive

Alright, let's not. My main point was really to point out another reason that $HOME/go is probably not problematic as a GOPATH default, as it's probably not the most "idiomatic Linux" path for local user installs of Go (a.k.a. GOROOT) anyway.

Other than that, I belive it has been discussed before to use XDG_CACHE_HOME for a default GOPATH, which was why I mentioned XDG_DATA_HOME -- although I don't know which role the authors of the linked document serve, or how "official" it is.

$HOME/work.......

@adg @quentinmit @rsc what are the next steps for this proposal?

Would really love to see something happen here. it's a frequent pain point in my classes. Any default (even $home/go which I disagree with :) ) is better than none.

$HOME/go it will be. There is no single best answer but this is short and sweet, and it can only be a problem to choose that name if $HOME/go already exists, which will only happy for experts who already have go installed and will understand GOPATH.

Who wants to do the work?

I'd be definitely happy to work on this.

@campoy, can you do it <= this Friday?

I'd say so, yes @bradfitz . It doesn't sound like a huge amount of code to be done.
I can start tomorrow.

update: I had a quick look at this and wrote some code already, will add some tests and send a change later today

This is great guys! 👍

@robpike did you consider also my alternative proposal in #17271? I would like to understand why this proposal was deemed better

It will not be a good idea to have names of Go install directory and workspace directory same i.e go because:

1) It is very easy for a naive user to corrupt/pollute the workspace if the user does tar -xzf go$VERSION.$OS-$ARCH.tar.gz in the home directory

2) A new user's default experience when not installing at /usr/local (doesn't want to install as root) will not be smooth as this will be the flow:
Download go$VERSION.$OS-$ARCH.tar.gz
tar -xzf go$VERSION.$OS-$ARCH.tar.gz --> installs in $HOME/go
export GOROOT=$HOME/go
export PATH=$PATH:$GOROOT/bin
go get something --> throws cannot download, $GOPATH must not be set to $GOROOT. For more details see: go help gopath

@krishnasrinivas it is my understanding that if GOROOT=$HOME/go, this default will either not take place or make go error since GOROOT and GOPATH cannot be the same. In such cases, as said before, it is expected that the user is capable enough to set their own GOPATH.

@mvdan correct, for new users who don't want to use root privileges for installation (and hence high chance of installing Go in ~/go) we are not making it any easier to get things up and running as they will have to explicitly set GOPATH to something else. This can be easily fixed if default GOPATH is either ~/gopath or ~/gocode

For non-root installation, if new users have to take advantage of default GOPATH=~/go then the installation documentation has to be made slightly more complicated by explicitly asking users to use tar -C option so as not to install it at ~/go

@rasky I consider #17271 and this proposal as orthogonal. The resolution of this proposal is an easy win that doesn't push us in any particular direction. I will elaborate further on that issue.

I agree with @krishnasrinivas. I didn't have root permissions, so I just untared Go to $HOME/go. I did also set my $GOPATH=$HOME/gowork.

@krishnasrinivas @joegrasse There is no perfect solution. It's easy to set GOPATH yourself, and I expect that that is what most people will do. The issue here is what we should do for the people who are newest to Go. These are not in general people who are installing their own Go distribution in custom locations. People who can figure out how to install Go in a custom location can figure out how to set GOPATH.

Think instead of a class of a new programmers who are using pre-installed Go distributions. We want them to be able to start writing Go code. We don't want the first step to be "this is what an environment variable is. This is how you set one. Now set GOPATH to this." Those steps have nothing to do with Go as such.

Again, there is no perfect solution, but it seems wise to pick something.

@ianlancetaylor I completely agree that something should be pick. I just believe with go untaring to ./go, defaulting to $HOME/go, might not be the best choice.

@ianlancetaylor GOPATH=$HOME/gopath is a better default than GOPATH=$HOME/go because of the aforementioned reasons.

I don't think the current name is a problem - if you know how to set PATH for a custom go/bin location under your homedir, you know how to set GOPATH.

@joegrasse @krishnasrinivas Take a look at "Installing to a custom location".

If you are untarring to anywhere other than /usr/local/go -- for reasons of permissions or otherwise -- it becomes necessary to set GOROOT as well, or compile from source.

As long as that is the case, there's no benefit in using $HOME/gopath, etc. over the proposed $HOME/go.

You assume that new users prefer to install from the tar.gz. I can cite no
numbers, but believe you answer is based towards Linux installations, which
are the third most popular installation target for go.

On Tue, 25 Oct 2016, 20:28 Krishna Srinivas [email protected]
wrote:

@mvdan https://github.com/mvdan correct, for users who don't want to
use root privileges for installation (and hence high chance of installing
Go in ~/go) we are not making it any easier to get things up and running as
they will have to explicitly set GOPATH to something else. This can be
easily fixed if GOPATH is either ~/gopath or ~/gocode

For non-root installation, if new users have to take advantage of default
GOPATH=~/go then the documentation has to be made slightly more complicated
by explicity asking users to use tar -C option so as not to install it at
~/go

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17262#issuecomment-255984498, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcAxqiBgwlXv4fk8CPk0gsd5h81yYmks5q3cvBgaJpZM4KI0I2
.

The docs all need to be updated too. That's probably the bulk of the work.

On 25 October 2016 at 10:14, Francesc Campoy [email protected]
wrote:

I'd say so, yes. It doesn't sound like a huge amount of code to be done.
I can start tomorrow.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17262#issuecomment-255892314, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIDilZGt_8O1bMsOu5Q-m1_tGDjxKQLkks5q3TvfgaJpZM4KI0I2
.

I'd say so, yes. It doesn't sound like a huge amount of code to be done.
I can start tomorrow.

On Mon, Oct 24, 2016 at 4:05 PM Brad Fitzpatrick [email protected]
wrote:

@campoy https://github.com/campoy, can you do it before <= this Friday?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17262#issuecomment-255890668, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACIkDKayusiOZWeOn6LrA49tlUsujwthks5q3TmqgaJpZM4KI0I2
.

I can help with the docs if necessary. The only problem is current material is solely depending on GOPATH as a reference point. For example,

"Or, as you have added $GOPATH/bin to your PATH, just type the binary name:"

or

"Create package under GOPATH, mkdir -p $GOPATH/src/github.com/user/hello"

Without engaging with GOPATH and learn what it is, it is almost impossible to get anything done in Go other than go getting third party packages. If we can report the default path via go env, that'd be easy to refer to that in docs.

Maybe $HOME/go/... could be substituted instead (or the equivalent on Windows)?

As you have added $HOME/go/bin to your PATH (or $GOPATH/bin if GOPATH is set)...

Perhaps at some point the documentation could expect individuals to not only set the PATH environment variable, but also set GOPATH to $HOME/go. Even though redundant, it prepares the user for later references to GOPATH.

Initial documentation could assume the default and not mention environment variables at all.

You assume that new users prefer to install from the tar.gz. I can cite no
numbers, but believe you answer is based towards Linux installations, which
are the third most popular installation target for go.

You are right, my opinion is biased towards Linux installations. I can see that for new users who install go in /usr/local, ~/go might be a more recognizable directory name than ~/gopath

Initial documentation could assume the default and not mention
environment variables at all?

Yup, hopefully all the distracting debate about setting GOPATH can be moved
to an appendix of the install documention, just liek we do for GOROOT
currently.

On Wed, 26 Oct 2016, 06:01 Nathan Youngman [email protected] wrote:

Maybe $HOME/go/... could be substituted instead (or the equivalent on
Windows)?

As you have added $HOME/go/bin to your PATH (or $GOPATH/bin if GOPATH is
set)...

Perhaps at some point the documentation could expect individuals to not
only set the PATH environment variable, but also set GOPATH to $HOME/go.
Even though redundant, it makes later documentation clear.

Initial documentation could assume the default and not mention environment
variables at all?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17262#issuecomment-256142424, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

Initial documentation could assume the default and not mention environment variables at all.

SGTM

There are two types of Go users:

• Users who just go-get existing packages
• Users who are Go developers

Default GOPATH is fixing the case for the first group. We still can keep GOPATH-related instructions around for the developers-facing docs. The installation shouldn't have to mention setting GOPATH at all anymore or we can have an appendix as @davecheney mentions.

As someone who had to rename ~/bin/go because of Go, I like to suggest that whatever the default, if it already exists then it has to have a .dotfile in it to indicate it's really Go's ~/go. When ~/go doesn't exist, go can create it, make the .dotfile, and future runs can find it. If I explicitly set GOPATH to ~/go then no .dotfile will be necessary as no default value is being used.

The dotfile exists. It's the src/ directory inside $HOME/go.

On Wed, 26 Oct 2016, 07:59 RalphCorderoy [email protected] wrote:

As someone who had to rename ~/bin/go because of Go, I like to suggest
that whatever the default, if it already exists then it has to have a
.dotfile in it to indicate it's really Go's ~/go. When ~/go doesn't exist,
go can create it, make the .dotfile, and future runs can find it. If I
explicitly set GOPATH to ~/go then no .dotfile will be necessary as no
default value is being used.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17262#issuecomment-256173981, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA4Vud3wlDe_npYNgKcGEWty6c3oYks5q3m2ngaJpZM4KI0I2
.

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

Even if some programmers are not aware of environment variables, they
should at least be familiar with _variables_. I think we're going to need
to use something to describe the location of a workspace in the docs, and
the string $GOPATH might as well be it.

On 26 October 2016 at 06:24, Jaana Burcu Dogan [email protected]
wrote:

Initial documentation could assume the default and not mention environment
variables at all.

SGTM

There are two types of Go users:

• Users who just go-get existing packages
• Users who are Go developers

Default GOPATH is fixing the case for the first group. We still can keep
GOPATH-related instructions around for the developers-facing docs. The
installation shouldn't have to mention setting GOPATH at all anymore or we
can have an appendix as @davecheney https://github.com/davecheney
mentions.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17262#issuecomment-256149104, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIDilZoQV3Ye3BOMS9uIMglI9GeDQeq7ks5q3ld3gaJpZM4KI0I2
.

Thanks is the intention, please see the original proposal.

In effect we can now say "go get will download the source to a folder
called, go/src/github.com/Foo/Bar inside your home directory"

On Wed, 26 Oct 2016, 06:01 Nathan Youngman [email protected] wrote:

Maybe $HOME/go/... could be substituted instead (or the equivalent on
Windows)?

As you have added $HOME/go/bin to your PATH (or $GOPATH/bin if GOPATH is
set)...

Perhaps at some point the documentation could expect individuals to not
only set the PATH environment variable, but also set GOPATH to $HOME/go.
Even though redundant, it makes later documentation clear.

Initial documentation could assume the default and not mention environment
variables at all?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17262#issuecomment-256142424, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

This would be a great issue for the last week of Hacktoberfest

The dotfile exists. It's the src/ directory inside $HOME/go

"src" is way to common to be a "this was created as a default GOPATH by Go" dotfile.

What is the thing you are trying to prevent?

On Wed, Oct 26, 2016 at 9:20 AM, RalphCorderoy [email protected]
wrote:

The dotfile exists. It's the src/ directory inside $HOME/go

"src" is way to common to be a "this was created as as default GOPATH by
Go" dotfile.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17262#issuecomment-256194536, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA057US0NKkEj669vwpatED2ECxA9ks5q3oChgaJpZM4KI0I2
.

$HOME/go it will be.

What will it be for Windows users?

Alex

Windows users will use %USERPROFILE%\go, same as Docker does here.

@davecheney, I'm trying to prevent what I said two hours ago: https://github.com/golang/go/issues/17262#issuecomment-256173981

Go is a common word. I had a ~/bin/go. Folks play Go and have source code to do with playing go. Nabbing ~/go by default when it already exists just because it happens to contain src is rude. If ~/go doesn't exist then Go may nab the name, create the directory, stamp it as golang's with a significant dotfile, e.g. based on the golang.org domain name.

That's the problem, and a possible solution, anyway. Even if the solution isn't the right one, that doesn't mean the problem doesn't exist.

I vote $HOME/golang

Thanks.

Can we use GOPATH default as ~/.gosrc ?

Can we use GOPATH default as ~/.gosrc ?

This will be hidden by default on Linux and OS X, and visible in Windows. What would be the motivation for hiding GOPATH?

The discussion on the value of the default took place a month ago. The decision on $HOME/go has been done and is already being implemented. Going back to that topic will only make the thread unbearably long.

Folks play Go and have source code to do with playing go.

I'm not really following you, but given that you will have set GOPATH to
something else already, there will be no impact to you.

On Wed, Oct 26, 2016 at 9:43 AM, RalphCorderoy [email protected]
wrote:

@davecheney https://github.com/davecheney, I'm trying to prevent what I
said two hours ago: #17262 (comment)
https://github.com/golang/go/issues/17262#issuecomment-256173981

Go is a common word. I had a ~/bin/go. Folks play Go and have source code
to do with playing go. Nabbing ~/go by default when it already exists just
because it happens to contain src is rude. If ~/go doesn't exist then Go
may nab the name, create the directory, stamp it as golang's with a
significant dotfile, e.g. based on the golang.org domain name.

That's the problem, and a possible solution, anyway. Even if the solution
isn't the right one, that doesn't mean the problem doesn't exist.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17262#issuecomment-256199766, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA-KTyB6tBYDEVVjHo9Aeb5szXVGbks5q3oYXgaJpZM4KI0I2
.

Hi @davecheney, This issue started with you proposing ~/gocode. Over time, it became ~/go. @robpike said above "it can only be a problem to choose that name if $HOME/go already exists, which will only happy for experts who already have go installed and will understand GOPATH". I think by being enveloped in golang for so long, you collectively are forgetting how common a word "go" is, and how it has other meanings, like the board game.

This change is aimed at newcomers to Go and some of them could have ~/go already for a non-Go use. I'm suggesting if go comes along, finds GOPATH isn't set, and no ~/go exists then it may create it, grabbing the name. But if ~/go does exist then it should only use it if it can tell it created it in an earlier GOPATH-less invocation. I suggested a dotfile be created as this flag. You said ~/go/src will serve as that flag. My objection is src itself isn't uncommon amongst programmers, i.e. those that might install Go. An unusual dotfile, e.g. ~/go/.default-gopath avoids this potential clash.

If they manually created ~/go for Go and run go without GOPATH then it won't use ~/go because the dotfile is missing. I think this is OK as by starting to set up a Go installation they should continue, setting GOPATH. They're not the simple "install package, run go(1)" case that's being targetted.

If none of this is considered a problem then that's fine. But for as long as you complain that you don't understand my point, I am doomed to keep attempting to explain it.

That's why I originally suggested a different path, with Rob's suggestion it's now officially out of my hands.

With that said, I'm happy that _a_ path has been chosen as I see that as the point of the exercise.

Wrt to your concerns, I recommend you follow https://go-review.googlesource.com/#/c/32019/ where precisely the issue you are concerned about is being discussed.

@RalphCorderoy, your concern is Go-the-board-game programmers having a ~/go directory for board game hacking?

Rob and Russ are very anti-dotfiles. It's better to state the problem than state the answer if the answer involves dotfiles (or symlinks).

@bradfitz, yes, ~/go already existing for gogame players, and further ~/go/src existing because they're programmer gogame players else they wouldn't be toying with Go. (I have ~/chess/src as it happens.)

adg's summary logic https://go-review.googlesource.com/c/32019/#message-09c4c4bbe1d840f07e0172ca9c7c3896a6c12f5c seems fine, and I'm in favour of creating ~/go if it doesn't exist, but test -d ~/go/src is a flaky test for using ~/go if there's no GOPATH.

If it wasn't ~/go, but something more unusual, like Dave's original suggestion, then it wouldn't matter. I think the surveys of what's currently used that showed ~/go was very popular aren't too helpful when the voters are Go programmers sufficiently keen to be following issues and social media.

@RalphCorderoy I'm think the amount of care and double underpants being engineered into CL 32019 is more than sufficient for the potential inconvenience to the small set of game-of-go-programmers who _have not_ used Go before version 1.8 and _have not_ set GOPATH _and_ also are beginning to learn Go, the language.

The go tool isn't going to delete or corrupt any non go code it comes across, you'll just get a slightly confusing message in a _few_ situations. To explain this, the go tool will not build Go source at the top of $GOPATH/src because that code is not within an importable package. Additionally, the other goal of this change is to make it easier to go get some code by providing a default location to download source to, so _if_ there was the-game-of-go source code in ~/go/src, the chances of it conflicting with a subdirectory derived from a go gettable repository are very remote, and even if that were to happen, either the go tool or git would crap out before any data was altered.

I think that the situation you are concerned about is very unlikely, and further mitigated by the explanation above.

(Just a likely valid argument against GOPATH=$HOME): Is the performance of goimports addressed? I remember something about a .goimport_ignore file. Otherwise performance for popular editors could suffer.

Thus, GOPATH!=$HOME is likely a collision-free/non-polluted option and should be performant.

@davecheney After go get I'd have crap to clear out of ~/go/{bin,src,pkg} and it wouldn't be a nice introduction to Go having pasted the line I found on the Internet.

@RalphCorderoy please understand the goal of this change is to make it easier for new Go users -- this isn't you -- you already have $GOPATH set, because you _have to_ with every version of Go from 1.1 onwards. The overlap between go-the-game users and _potential_ go-the-programming-language users is very very small. I don't think there will be an issue.

@RalphCorderoy The situation you're describing is rare, and anyone running shell commands from a random website shouldn't have expectations that their disks won't be wiped, let alone some files downloaded and shuffled around in an eponymous directory. (Edit: Consider Wine auto-creating and modifying .wine in the user's home directory. What if the user has something else there? After all, "wine" is a term we use for a particular beverage.)

The naming collision between "Go" the language and "Go" the board game is certainly understood and well known. The filesystem is a shared resource, collisions happen and are inevitable.

@davecheney, Please stop telling me this change isn't aimed at helping me because I am not a new Go user. I have always been aware of that even before you started to point it out. I also understand your position is len(intersect(existing-~/go, GOPATH-less)) is too small to be of concern.

After having cleaned up the go-get spew in ~/go because he'd know what wasn't normally there, he'd then have to research to see what else the command(s) may have done under $HOME in case more clean up was required.

unsubscribe

I'm sorry if I've caused you any offence. I no longer wish to correspond
with you on this issue. Thank you.

On Fri, Oct 28, 2016 at 3:28 AM, RalphCorderoy [email protected]
wrote:

@davecheney https://github.com/davecheney, Please stop telling me this
change isn't aimed at helping me because I am not a new Go user. I have
always been aware of that even before you started to point it out. I also
understand your position is len(intersect(existing-~/go, GOPATH-less)) is
too small to be of concern.

After having cleaned up the go-get spew in ~/go because he'd know what
wasn't normally there, he'd then have to research to see what else the
command(s) may have done under $HOME in case more clean up was required.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17262#issuecomment-256697043, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcAyE8xRIcxvwgRfalJoqZa3TBU9Z3ks5q4NEcgaJpZM4KI0I2
.

davecheney, No, not offence. Just there's no point keep covering the same ground.

Just wondering – what's the expected behavior if $HOME is not set?

While I've never worked on a system where that was the case, it seems possible someone has modified their default env vars for some reason, and this edge case should be handled consistently.

I think it currently evaluates $GOPATH=''; does that mean it's going use the current working directory?

use the current working directory

It occurred to me that this might be the most useful to a new Go user that hasn't set GOPATH. A go get would be similar to a wget, etc., filling the current directory. They aren't interested in the path aspect of GOPATH at this point, and quite possibly want their every venture into playing around with different online stuff to be distinct, as a new temporary directory of their own making would give them. They can get, run, and easily delete, the different repos they see referenced.

• if GOPATH not set:
  
  
  
  • if only one or two, but not all, of ~/{bin,pkg,src} exist:
  
  
  • they have to set GOPATH, pkg is the unusual one
  
  
  • else either all or none exist:
  
  
  • ensure they all exist
  
  
  • GOPATH=$(pwd)
  
  

I have mixed feelings on this, but my prevailing sentiment (as someone who has set $GOPATH) is that go get behavior should be "deterministic" and always install things under $GOPATH – a consistent and well-documented destination.

Even though I'm unaffected by this change, it feels weird that go get will download things to different locations depending on what the working directory is when the command is issued. I'm aware this is what wget, npm install, and other tools do, but it feels like a departure from the idea of a consistent $GOPATH value (which is how I interpreted the spirit of this change).

If this is beyond the scope of this issue, I'd propose simply exiting and outputting an error if $HOME is actually unset.

I have taught 5 new programmers who came from the Java world in a 3rd world country .. They all were confused for sure about GOPATH. Heck, I was too when I started back before Go 1 was released. I personally use "$HOME/gopath" but I suggest that "go get" command points them to a go blog that is CLEAR on how to create a go path for their operating system. That's all we need. Some guidance by the "go get" command that isn't a spec.. But a damn simple blog post!!

Obviously I mean when no GOPATH has been set. Just update the error message that currently gets displayed. The adoption rate is there already.. Just need a bit of help instead of the current google it up method that new comers are doing.

@einthusan I feel like it's pretty well-documented on https://golang.org/doc/code.html#GOPATH, but I don't know how many people getting started with Go actually read this page.

Sorry to spam.. After doing some googling.. I think "go get" should just prompt the user saying "No GOPATH has been set... Would you like to use the current working directory as your temporary GOPATH?" (Yes/No)

@einthusan, there is no precedent for cmd/go doing interactive prompts.

If the new default GOPATH is $HOME/go. Would not people expect this https://hub.docker.com/_/golang/ to adopt the same beheviour?

@cescoferraro that's a question for the maintainers of that image. Despite it being labelled as "official", that project is not affiliated with Go.

Answering/responding to my own question about unset $HOME:

In the current implementation (the CL is linked above), $GOPATH defaults to "" if $HOME is unset: https://go-review.googlesource.com/#/c/32019/11/src/go/build/build.go I think this is consistent with current behavior.

I believe this edge case is very unlikely since $HOME is always set in a normal login session, which is likely the case for most Go programmers. Although I would personally _like_ the behavior to be explicitly clarified, it seems like there are no "side effects" (like installing things in working dir). Correct me if I'm wrong. :)

If this is to make easier for people who start with Go for first time, let it be something like the current path:

GOPATH=$(pwd)

Setting export GOPATH=$(pwd) makes it easy for switching between projects

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.