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

Closed
davecheney opened this Issue Sep 28, 2016 · 137 comments

Projects

None yet
@davecheney
Contributor
davecheney commented Sep 28, 2016 edited

This proposal is a simplification of #12488.

In short, if the user has not set $GOPATH in their environment the go tool will default to a value of GOPATH=$HOME/gocode.


Rationale
At the moment all the documentation we have says "you have to set a GOPATH", then people get distracted and upset because they don't understand why they have to do this.

By choosing a default GOPATH, we can make our documentation easier because we can say things like

$ go get github.com/foo/bar

will check out the github.com/foo/bar repo into $HOME/gocode/src/github.com/foo/bar.

We don't need to distract newcomers with having to set an env var, all we need to do is put a little parenthetical note at the bottom of the page

$HOME/gocode is the default path to your go workspace. If you want to change this path, set the GOPATH variable to something of your choosing.

Compatibility
This proposal only changes the experience for newcomers who have not chosen to set a $GOPATH variable. For anyone using Go 1.1-1.7 today, your experience will be unchanged as you are currently required to set $GOPATH.

@davecheney davecheney changed the title from proposal: go tool assumes GOPATH=$HOME/gocode if not set to proposal: assume GOPATH=$HOME/gocode if not set Sep 28, 2016
@davecheney davecheney added the Proposal label Sep 28, 2016
@campoy
Member
campoy commented Sep 28, 2016

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

@rsc
Contributor
rsc commented Sep 28, 2016

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

@cespare
Contributor
cespare commented Sep 28, 2016

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

@ianlancetaylor
Contributor

Do we have any information about what most people do?

I use GOPATH=$HOME/gopath myself.

@bradfitz
Member

Thumbs up here if you currently use GOPATH=$HOME

@bradfitz
Member

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

@bradfitz
Member

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

@campoy
Member
campoy commented Sep 28, 2016

Should I do a twitter poll on @golang?

@bradfitz
Member

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

@freeformz
Contributor

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

@freeformz
Contributor
freeformz commented Sep 28, 2016 edited

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.

@campoy
Member
campoy commented Sep 28, 2016

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
.

@rakyll
Member
rakyll commented Sep 28, 2016 edited

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

@freeformz
Contributor

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

@davecheney
Contributor
davecheney commented Sep 28, 2016 edited

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.

@rakyll
Member
rakyll commented Sep 28, 2016

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

@davecheney
Contributor

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

@rsc
Contributor
rsc commented Sep 28, 2016

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.

@davecheney
Contributor
davecheney commented Sep 28, 2016 edited

@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!
@adg
Contributor
adg commented Sep 28, 2016 edited

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

@rakyll
Member
rakyll commented Sep 28, 2016

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.

@mvdan
Contributor
mvdan commented Sep 28, 2016

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.

@davecheney
Contributor
davecheney commented Sep 28, 2016 edited

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

@alexbrainman
Contributor

@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

@davecheney
Contributor
davecheney commented Sep 29, 2016 edited

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.

@broady
Contributor
broady commented Sep 29, 2016 edited

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.

@alexbrainman
Contributor

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

@mattn
Member
mattn commented Sep 29, 2016

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.

@cznic
Contributor
cznic commented Sep 29, 2016

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

@geosoft1
geosoft1 commented Sep 29, 2016 edited

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.

@hnakamur

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.

@tbroyer
tbroyer commented Sep 29, 2016

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

@mattn
Member
mattn commented Sep 29, 2016

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

@dvrkps
dvrkps commented Sep 29, 2016

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 ?

@SamWhited
Contributor

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.

@rsc
Contributor
rsc commented Sep 29, 2016

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.

@geosoft1
geosoft1 commented Sep 29, 2016 edited

$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.

@randall77
Contributor

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

@btracey
Contributor
btracey commented Sep 29, 2016

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.

@bradfitz
Member

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

@adg
Contributor
adg commented Sep 29, 2016

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 notifications@github.com
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
#17262 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIDilc6cjWl0r3-V-6FWruHIiYA_X4nJks5qvDc5gaJpZM4KI0I2
.

@btracey
Contributor
btracey commented Sep 29, 2016

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

@davecheney
Contributor

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 notifications@github.com 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
#17262 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA_e53SwZ7Zf_rWCcbZTyPEmXXhUTks5qvD1JgaJpZM4KI0I2
.

@btracey
Contributor
btracey commented Sep 29, 2016

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).

@davecheney
Contributor

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 notifications@github.com 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
#17262 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA_CKox90AQMMAxOs9wEL2ffY0S0zks5qvEUPgaJpZM4KI0I2
.

@douglarek
douglarek commented Sep 30, 2016 edited

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

@btracey
Contributor
btracey commented Sep 30, 2016

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

@rsc
Contributor
rsc commented Sep 30, 2016

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.)

@randall77
Contributor

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

@btracey
Contributor
btracey commented Sep 30, 2016 edited

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.

@rsc
Contributor
rsc commented Sep 30, 2016 edited

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

@minux
Member
minux commented Sep 30, 2016
@smyrman
smyrman commented Oct 2, 2016 edited

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.

@SamWhited
Contributor
SamWhited commented Oct 3, 2016 edited

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.

@adg
Contributor
adg commented Oct 3, 2016
@davecheney
Contributor

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 notifications@github.com 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
#17262 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA2kwyq0Iuidk0ygsGzqVKGLkKBR9ks5qwXkDgaJpZM4KI0I2
.

@smyrman
smyrman commented Oct 4, 2016 edited

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.

@quentinmit quentinmit modified the milestone: Proposal Oct 4, 2016
@dup2X
dup2X commented Oct 11, 2016

$HOME/work.......

@davecheney
Contributor

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

@bketelsen
Contributor

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.

@robpike
Contributor
robpike commented Oct 24, 2016

$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.

@adg adg changed the title from proposal: assume GOPATH=$HOME/gocode if not set to proposal: assume GOPATH=$HOME/go if not set Oct 24, 2016
@adg
Contributor
adg commented Oct 24, 2016

Who wants to do the work?

@bradfitz bradfitz modified the milestone: Go1.8, Proposal Oct 24, 2016
@campoy
Member
campoy commented Oct 24, 2016

I'd be definitely happy to work on this.

@bradfitz
Member
bradfitz commented Oct 24, 2016 edited

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

@campoy
Member
campoy commented Oct 24, 2016 edited

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

@campoy
Member
campoy commented Oct 24, 2016

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

@matiasinsaurralde

This is great guys! 👍

@bradleyfalzon bradleyfalzon referenced this issue in bradleyfalzon/apicompat Oct 25, 2016
Open

Monitor default GOPATH discussion #32

@rasky
Contributor
rasky commented Oct 25, 2016

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

@krishnasrinivas

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

@mvdan
Contributor
mvdan commented Oct 25, 2016

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

@krishnasrinivas
krishnasrinivas commented Oct 25, 2016 edited

@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

@adg
Contributor
adg commented Oct 25, 2016

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

@joegrasse

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.

@ianlancetaylor
Contributor

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

@joegrasse

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

@krishnasrinivas

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

@mccoyst
Contributor
mccoyst commented Oct 25, 2016

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.

@nathany
Contributor
nathany commented Oct 25, 2016

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

@davecheney
Contributor

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 notifications@github.com
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
#17262 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcAxqiBgwlXv4fk8CPk0gsd5h81yYmks5q3cvBgaJpZM4KI0I2
.

@adg
Contributor
adg commented Oct 25, 2016

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 notifications@github.com
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
#17262 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIDilZGt_8O1bMsOu5Q-m1_tGDjxKQLkks5q3TvfgaJpZM4KI0I2
.

@campoy
Member
campoy commented Oct 25, 2016

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 notifications@github.com
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
#17262 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACIkDKayusiOZWeOn6LrA49tlUsujwthks5q3TmqgaJpZM4KI0I2
.

@rakyll
Member
rakyll commented Oct 25, 2016

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.

@nathany
Contributor
nathany commented Oct 25, 2016 edited

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.

@krishnasrinivas

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

@davecheney
Contributor

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 notifications@github.com 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
#17262 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

@rakyll
Member
rakyll commented Oct 25, 2016

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.

@RalphCorderoy

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.

@davecheney
Contributor

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

On Wed, 26 Oct 2016, 07:59 RalphCorderoy notifications@github.com 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
#17262 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA4Vud3wlDe_npYNgKcGEWty6c3oYks5q3m2ngaJpZM4KI0I2
.

@gopherbot

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

@adg
Contributor
adg commented Oct 25, 2016

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 notifications@github.com
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
#17262 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIDilZoQV3Ye3BOMS9uIMglI9GeDQeq7ks5q3ld3gaJpZM4KI0I2
.

@davecheney
Contributor

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 notifications@github.com 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
#17262 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcAwUgsP6A9CzCzmeeQG1nGXBGLyvQks5q3lHzgaJpZM4KI0I2
.

@ChrisMcKenzie

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

@RalphCorderoy
RalphCorderoy commented Oct 25, 2016 edited

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.

@davecheney
Contributor

What is the thing you are trying to prevent?

On Wed, Oct 26, 2016 at 9:20 AM, RalphCorderoy notifications@github.com
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
#17262 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA057US0NKkEj669vwpatED2ECxA9ks5q3oChgaJpZM4KI0I2
.

@alexbrainman
Contributor

$HOME/go it will be.

What will it be for Windows users?

Alex

@campoy
Member
campoy commented Oct 25, 2016 edited

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

@RalphCorderoy

@davecheney, I'm trying to prevent what I said two hours ago: #17262 (comment)

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.

@prsolucoes

I vote $HOME/golang

Thanks.

@tschottdorf tschottdorf added a commit to tschottdorf/cockroach that referenced this issue Oct 26, 2016
@tschottdorf tschottdorf scripts: make gceworker GOPATH=~/go
This follows what will be the default in go1.8 and forward.
See golang/go#17262.
3809bb7
@tschottdorf tschottdorf referenced this issue in cockroachdb/cockroach Oct 26, 2016
Merged

scripts: make gceworker's GOPATH=~/go #10225

@tschottdorf tschottdorf added a commit to tschottdorf/cockroach that referenced this issue Oct 26, 2016
@tschottdorf tschottdorf scripts: make gceworker's GOPATH=~/go
This follows what will be the default in go1.8 and forward.
See golang/go#17262.
7edc953
@denismakogon

Can we use GOPATH default as ~/.gosrc ?

@ironiridis

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?

@mvdan
Contributor
mvdan commented Oct 26, 2016

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.

@davecheney
Contributor

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 notifications@github.com
wrote:

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

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
#17262 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA-KTyB6tBYDEVVjHo9Aeb5szXVGbks5q3oYXgaJpZM4KI0I2
.

@rsc rsc changed the title from proposal: assume GOPATH=$HOME/go if not set to cmd/go: assume GOPATH=$HOME/go if not set Oct 27, 2016
@RalphCorderoy

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.

@davecheney
Contributor
davecheney commented Oct 27, 2016 edited

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.

@bradfitz
Member

@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).

@RalphCorderoy

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

@davecheney
Contributor
davecheney commented Oct 27, 2016 edited

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

@djui
djui commented Oct 27, 2016

(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.

@RalphCorderoy

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

@davecheney
Contributor

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

@ironiridis
ironiridis commented Oct 27, 2016 edited

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

@RalphCorderoy

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

@bketelsen
Contributor

unsubscribe

@davecheney
Contributor

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 notifications@github.com
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
#17262 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcAyE8xRIcxvwgRfalJoqZa3TBU9Z3ks5q4NEcgaJpZM4KI0I2
.

@RalphCorderoy

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

@peggyl
peggyl commented Oct 27, 2016

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?

@RalphCorderoy

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)
@peggyl
peggyl commented Oct 27, 2016

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.

@einthusan

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!!

@einthusan

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.

@peggyl
peggyl commented Oct 29, 2016

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

@einthusan

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)

@bradfitz
Member

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

@cescoferraro

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

@davecheney
Contributor

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

@peggyl
peggyl commented Nov 1, 2016

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. :)

@jinmatt
jinmatt commented Nov 2, 2016 edited

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

@campoy
Member
campoy commented Nov 2, 2016

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.

@jinmatt
jinmatt commented Nov 2, 2016

@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)
@campoy
Member
campoy commented Nov 2, 2016

@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).

@rsc
Contributor
rsc commented Nov 2, 2016 edited

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.

@nathany
Contributor
nathany commented Nov 2, 2016

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

@rsc
Contributor
rsc commented Nov 3, 2016

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

@gopherbot gopherbot pushed a commit that referenced this issue Nov 11, 2016
@campoy @campoy campoy + campoy go/build: implement default GOPATH
Whenever GOPATH is not defined in the environment, use $HOME/go
as its default value. For Windows systems use %USERPROFILE%/go
and $home/go for plan9.

The choice of these environment variables is based on what Docker
currently does. The os/user package is not used to avoid having
a cgo dependency.

Updates #17262. Documentation changes forthcoming.

Change-Id: I6368fbfbc5afda99d6e64c35c1980076fcf45344
Reviewed-on: https://go-review.googlesource.com/32019
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
dc4a815
@gopherbot

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

@rsc rsc removed the Proposal label Nov 21, 2016
@quentinmit quentinmit added the NeedsFix label Nov 22, 2016
@gopherbot

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

@gopherbot gopherbot pushed a commit that closed this issue Nov 30, 2016
@rsc rsc doc, cmd/go: adjust documentation for default GOPATH
Replaces CL 33356.

Fixes #17262.

Change-Id: Idfb2343e90771775e51a66c63760f458737a288c
Reviewed-on: https://go-review.googlesource.com/33730
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
74628a8
@gopherbot gopherbot closed this in 74628a8 Nov 30, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment