lint target no longer works without $GOPATH

[porridge]

What happened:

Checked out master and ran:

$ LANG=C make lint
if [ ! -f /bin/golangci-lint ]; then ./hack/install-golangcilint.sh; fi
golangci/golangci-lint info checking GitHub for tag 'v1.23.7'
golangci/golangci-lint info found version: 1.23.7 for v1.23.7/linux/amd64
golangci/golangci-lint info installed /home/porridge/go/bin/golangci-lint
/bin/golangci-lint run
/bin/bash: /bin/golangci-lint: No such file or directory
make: *** [Makefile:51: lint] Error 127

What you expected to happen:

Lint should pass on a clean repo.

How to reproduce it (as minimally and precisely as possible):

make lint

Anything else we need to know?:

• I don't have GOPATH set, which might be related.
• I think there was a recent bump of the linter cc @zen-dog

[porridge]

Looks like this was changed recently by #1362
cc @ANeumann82 @nfnt

[nfnt]

GOPATH has to be set. This drawback is discussed in #1362.

[porridge]

GOPATH has to be set. This drawback is discussed in #1362.

I did read that PR, but I don't see the connection. AFAICT the only requirement is for your $GOBIN to be in your $PATH. One does not need $GOPATH at all these days, it's optional. Am I missing something?

[porridge]

Also, the code as is will still be incorrect if one's $GOBIN is set to something else than $GOPATH/bin.

[ANeumann82]

I don't see anything about not needing the $GOPATH...

 If no GOPATH is set, it is assumed to be $HOME/go

So, I'm fine with defaulting it to ~/go if it's not set inside the makefile.

[kensipe]

This fails on my machine as well and I have GOPATH setup :(

[kensipe]

ERRO Running error: context loading failed: failed to load program with go/packages: could not determine GOARCH and Go compiler

[gerred]

Wouldn't it be better to just use something like direnv, add an .envrc to this folder, prepend $GOPATH/bin to PATH (although I just have it set in my PATH anyway), and call it a day? .gitignore it even if we want to.

It's important everyone can use their own tools, their way, but I think we can make some reasonable assumptions here given how Go and their binaries tend to work. This will all even cause hell with VSCode which has a tools specific GOPATH as well, that some people use!

While other languages are great at being hermetically sealed from their environments from both a binary and package perspective (really, any language with a sane package manager), Go isn't that language. We have plenty other things to do than continuously work around Go's annoying shortcomings.

As part of that, we'd revert the changes in #1362.

[kensipe]

the issue I had ^^ was my env... I was looking at go 1.14 over the weekend. I am good either way.