New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
@davecheney
Contributor

davecheney commented Sep 28, 2016

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

@bradfitz

This comment has been minimized.

Show comment
Hide comment
@campoy

This comment has been minimized.

Show comment
Hide comment
@campoy

campoy Sep 28, 2016

Contributor

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

Contributor

campoy commented Sep 28, 2016

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

@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Sep 28, 2016

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@cespare

cespare Sep 28, 2016

Contributor

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

Contributor

cespare commented Sep 28, 2016

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

@ianlancetaylor

This comment has been minimized.

Show comment
Hide comment
@ianlancetaylor

ianlancetaylor Sep 28, 2016

Contributor

Do we have any information about what most people do?

I use GOPATH=$HOME/gopath myself.

Contributor

ianlancetaylor commented Sep 28, 2016

Do we have any information about what most people do?

I use GOPATH=$HOME/gopath myself.

@bradfitz

This comment has been minimized.

Show comment
Hide comment
@bradfitz

bradfitz Sep 28, 2016

Member

Thumbs up here if you currently use GOPATH=$HOME

Member

bradfitz commented Sep 28, 2016

Thumbs up here if you currently use GOPATH=$HOME

@bradfitz

This comment has been minimized.

Show comment
Hide comment
@bradfitz

bradfitz Sep 28, 2016

Member

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

Member

bradfitz commented Sep 28, 2016

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

@bradfitz

This comment has been minimized.

Show comment
Hide comment
@bradfitz

bradfitz Sep 28, 2016

Member

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

Member

bradfitz commented Sep 28, 2016

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

@campoy

This comment has been minimized.

Show comment
Hide comment
@campoy

campoy Sep 28, 2016

Contributor

Should I do a twitter poll on @golang?

Contributor

campoy commented Sep 28, 2016

Should I do a twitter poll on @golang?

@bradfitz

This comment has been minimized.

Show comment
Hide comment
@bradfitz

bradfitz Sep 28, 2016

Member

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

Member

bradfitz commented Sep 28, 2016

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

@freeformz

This comment has been minimized.

Show comment
Hide comment
@freeformz

freeformz Sep 28, 2016

Contributor

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

Contributor

freeformz commented Sep 28, 2016

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

@freeformz

This comment has been minimized.

Show comment
Hide comment
@freeformz

freeformz Sep 28, 2016

Contributor

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.

Contributor

freeformz commented Sep 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@campoy

campoy Sep 28, 2016

Contributor

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
.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@rakyll

rakyll Sep 28, 2016

Member

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

Member

rakyll commented Sep 28, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@freeformz

freeformz Sep 28, 2016

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.

Contributor

freeformz commented Sep 28, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@davecheney

davecheney Sep 28, 2016

Contributor

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.

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@rakyll

rakyll Sep 28, 2016

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@davecheney

davecheney Sep 28, 2016

Contributor

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

Contributor

davecheney commented Sep 28, 2016

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

@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Sep 28, 2016

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@davecheney

davecheney Sep 28, 2016

Contributor

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

davecheney commented Sep 28, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@adg

adg Sep 28, 2016

Contributor

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

Contributor

adg commented Sep 28, 2016

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

@rakyll

This comment has been minimized.

Show comment
Hide comment
@rakyll

rakyll Sep 28, 2016

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@mvdan

mvdan Sep 28, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@davecheney

davecheney Sep 28, 2016

Contributor

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

Contributor

davecheney commented Sep 28, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@alexbrainman

alexbrainman Sep 29, 2016

Member

@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

Member

alexbrainman commented Sep 29, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@davecheney

davecheney Sep 29, 2016

Contributor

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.

Contributor

davecheney commented Sep 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@broady

broady Sep 29, 2016

Member

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.

Member

broady commented Sep 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@alexbrainman

alexbrainman Sep 29, 2016

Member

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

Member

alexbrainman commented Sep 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mattn

mattn Sep 29, 2016

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@cznic

cznic Sep 29, 2016

Contributor

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

Contributor

cznic commented Sep 29, 2016

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

@geosoft1

This comment has been minimized.

Show comment
Hide comment
@geosoft1

geosoft1 Sep 29, 2016

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.

geosoft1 commented Sep 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@hnakamur

hnakamur Sep 29, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@tbroyer

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

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

This comment has been minimized.

Show comment
Hide comment
@mattn

mattn Sep 29, 2016

Member

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

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

This comment has been minimized.

Show comment
Hide comment
@dvrkps

dvrkps Sep 29, 2016

Contributor

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 ?

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@SamWhited

SamWhited Sep 29, 2016

Member

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.

Member

SamWhited commented Sep 29, 2016

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.

@bradfitz

This comment has been minimized.

Show comment
Hide comment
@bradfitz

bradfitz Oct 29, 2016

Member

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

Member

bradfitz commented Oct 29, 2016

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

@cescoferraro

This comment has been minimized.

Show comment
Hide comment
@cescoferraro

cescoferraro Nov 1, 2016

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

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

@davecheney

This comment has been minimized.

Show comment
Hide comment
@davecheney

davecheney Nov 1, 2016

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.

Contributor

davecheney commented Nov 1, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@peggyl

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

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

This comment has been minimized.

Show comment
Hide comment
@jinmatt

jinmatt Nov 2, 2016

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

jinmatt commented Nov 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@campoy

campoy Nov 2, 2016

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jinmatt

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

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

This comment has been minimized.

Show comment
Hide comment
@campoy

campoy Nov 2, 2016

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Nov 2, 2016

Contributor

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.

Contributor

rsc commented Nov 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nathany

nathany Nov 2, 2016

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Nov 3, 2016

Contributor

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

Contributor

rsc commented Nov 3, 2016

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

gopherbot pushed a commit that referenced this issue Nov 11, 2016

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

This comment has been minimized.

Show comment
Hide comment

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

This comment has been minimized.

Show comment
Hide comment

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

@gopherbot gopherbot closed this in 74628a8 Nov 30, 2016

yegortimoshenko added a commit to yegortimoshenko/dotfiles that referenced this issue Feb 14, 2017

Refactor .profile
Drop GOPATH (see golang/go#17262), move math alias to ~/bin.

yegortimoshenko added a commit to yegortimoshenko/dotfiles that referenced this issue Jul 12, 2017

Refactor .profile
Drop GOPATH (see golang/go#17262), move math alias to ~/bin.

yegortimoshenko added a commit to yegortimoshenko/dotfiles that referenced this issue Jul 12, 2017

Refactor .profile
Drop GOPATH (see golang/go#17262), move math alias to ~/bin.

sschuberth added a commit to sschuberth/LicenseFinder that referenced this issue Sep 21, 2017

Fall back to a default GOPATH
This avoids the need to have GOPATH set and is in line with how Go itself
behaves, see golang/go#17262.

sschuberth added a commit to sschuberth/LicenseFinder that referenced this issue Sep 21, 2017

Fall back to a default GOPATH
This avoids the need to have GOPATH set and is in line with how Go itself
behaves, see golang/go#17262.

While at it, make the workspace directory check a bit stricter by really
checking for a directory.

kdykeman added a commit to pivotal-legacy/LicenseFinder that referenced this issue Sep 21, 2017

Fall back to a default GOPATH
This avoids the need to have GOPATH set and is in line with how Go itself
behaves, see golang/go#17262.

While at it, make the workspace directory check a bit stricter by really
checking for a directory.

tanzeeb added a commit to tanzeeb/bash-it that referenced this issue Oct 14, 2017

Change default $GOPATH to $HOME/go
As of Go v1.8, $HOME/go is the default $GOPATH. See golang/go#17262 for the discussion.

@golang golang locked and limited conversation to collaborators Nov 30, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.