Proposal: go get should exit if GOPATH is not set

[Dave Cheney]

Hello,

A frequent problem reported on IRC is the go tool not working
properly. We've gotten pretty good at debugging the issue to these
culprits.

1. GOPATH is not exported.
2. while 1 was in effect, go get downloaded the source to
$GOROOT/src/pkg and now aliases any other copy of the source.

I would like to propose that a change be made to the go tool so that
it will not fetch third party source if GOPATH is not set. While there
are cases where not having a GOPATH is valid, I think that go get is
not one of them and this will solve the first issue, and by doing so,
reduce the frequency of the second.

A sample proposal is available at http://codereview.appspot.com/6397048/

I look forward to your feedback.

Cheers

Dave

[Andrew Gerrand]

I'm with this proposal.

Even though it works, it's almost always the wrong thing to install
external packages inside GOROOT. I now feel that it was a mistake to
allow it in the first place.

Perhaps people who want to install external packages inside GOROOT can
hack their go tool to permit it. That shouldn't be a big deal as
they'd already have a writable GOROOT.

Andrew

[Jan Mercl]

On Mon, Jul 16, 2012 at 6:37 AM, Dave Cheney <da...@cheney.net> wrote:

I look forward to your feedback.

Personally I'm fine with this (as I don't need to install packages to $GOROOT/whatever). But I don't know if the compatibilty promise covers also scripts invoking Go 1 tools...? There might be some which will get broken by the CL, IIUC.

-j 

[Andrew Gerrand]

Nope, the compatibility promise doesn't cover the tools.

[Brad Fitzpatrick]

On Mon, Jul 16, 2012 at 1:20 PM, Andrew Gerrand <a...@golang.org> wrote:

Nope, the compatibility promise doesn't cover the tools.

Just because we don't have an automated check for it doesn't mean the promise isn't there.

It would suck if I did apt-get update golang-go and my Go hypothetically updated from 1.0.5 to 1.1.2 and suddenly my go-get-proxy service stops working because the command line flags or verbs changed.

Maybe this change is okay, but I wouldn't go so far as to say that the compatibility promise doesn't apply to the tools.

[Patrick Mylund Nielsen]

Definitely agree. GOPATH seems to be the thing that gets the most people stuck. It would be great if the tool warned about an unexported GOPATH, and possibly included instructions or linked to a page with instructions for the different platforms. (It's easy to do GOPATH=/home/foo/bar; go, in bash, but it doesn't work, and nothing tells you why.) That you can just have one directory in GOPATH for everything also isn't obvious to newcomers.

[Andrew Gerrand]

But it doesn't, yo: http://golang.org/doc/go1compat.html#tools

[Brad Fitzpatrick]

Break all the things!

[Andrew Gerrand]

goinstall had a weird heuristic: if something went wrong when remotely
installing something and you didn't have GOPATH set, it would say
"Hey, this didn't work, try setting GOPATH".

It was correct sometimes, but it was also wrong sometimes. And it was
particularly confounding to people who had non-GOPATH-related issues.

That's why I'm in favor of this, at least tentatively. If it's just a
case of "No, do this first," then that's an instruction/diagnostic we
can give reliably.

Curious to hear more people's thoughts.

[Kyle Lemons]

I'm with you, but I originally assumed that I'm biased toward making things easier on me as a helper on the mailing list and IRC (since it would remove a huge class of common questions) and that this thread would light up with people in support of packages in GOROOT; since it hasn't, I'm less sure that I'm in the minority on this one :).  I was an early adopter of GOPATH, so I find it somewhat difficult to gauge community opinion on it.

[Patrick Mylund Nielsen]

Most people I've seen have done this by putting GOROOT in GOPATH. I think the argument for "no-conf" in non-default locations is pretty slim since you'd have to set GOROOT anyway.

> I originally assumed that I'm biased toward making things easier on me as a helper on the mailing list and IRC (since it would remove a huge class of common questions) 

Or, put another way: this would Go a lot easier to use for a lot of people. It's definitely a top 3 question. As long as the error message isn't ambiguous, why not?

[Dave Cheney]

Thank you all for your considered comments. I'll hg mail this proposal
for wider review.

[Andrew Gerrand]

On 16 July 2012 16:28, Dave Cheney <da...@cheney.net> wrote:
> Thank you all for your considered comments. I'll hg mail this proposal
> for wider review.

I'd prefer to decide exactly what we should do before doing the code part.

In particular I'd like to hear from Russ, as he designed the thing in
the first place. He's just returning from holidays so it'll probably
take him a bit to catch up.

Andrew

[Russ Cox]

I am not comfortable with this proposal. If I want to put all my code
in $GOROOT, I should not have some tool telling me I can't. Especially
since there might already be people working this way.

I don't understand the problems being reported on IRC. If the code
gets downloaded once into $GOROOT, don't future go get's update that
copy of the code? What's the problem, other than the location being
unexpected?

It also seems like go list -f '{{.Dir}}' pkg/path would be a trivial
way to diagnose this.

Russ

[Patrick Mylund Nielsen]

IMO the biggest problem is not being able to tell, e.g. via go env, or having the Go tool tell you when you there's an error and GOPATH isn't in go's environ, e.g. "Is GOPATH set correctly? See 'go doc gopath'". A common problem is GOPATH=/home/foo/go; go build -> "why doesn't it work?"

[Russ Cox]

On Sun, Jul 29, 2012 at 11:24 PM, Patrick Mylund Nielsen
<pat...@patrickmylund.com> wrote:
> IMO the biggest problem is not being able to tell, e.g. via go env, or
> having the Go tool tell you when you there's an error and GOPATH isn't in
> go's environ, e.g. "Is GOPATH set correctly? See 'go doc gopath'". A common
> problem is GOPATH=/home/foo/go; go build -> "why doesn't it work?"

The biggest problem is not being able to tell what?

[Patrick Mylund Nielsen]

Sorry -- 'go env' doesn't show GOPATH (unless that changed recently) so you can't easily tell if GOPATH is "visible" to go or not, i.e. if it is actually exported, so many end up spending a lot of time wondering what they have to do with those folders when in reality they set GOPATH instead of exporting it in bash.

[Russ Cox]

On Sun, Jul 29, 2012 at 11:52 PM, Patrick Mylund Nielsen
<pat...@patrickmylund.com> wrote:
> Sorry -- 'go env' doesn't show GOPATH (unless that changed recently) so you
> can't easily tell if GOPATH is "visible" to go or not, i.e. if it is
> actually exported, so many end up spending a lot of time wondering what they
> have to do with those folders when in reality they set GOPATH instead of
> exporting it in bash.

CL 6446064.