Should "go install module@version" interact with ~/.local/bin?

[Tyler Compton]

With recent changes to go install, we now have an official, module-aware way to locally build and install Go tools. This is a great step, but I wonder if some renewed consideration should be made to where the tools are installed.

As I'm sure you all know, go install puts binaries in $GOPATH/bin or $HOME/go/bin by default. I think that made more sense in a world where the GOPATH was our primary means of Go development. However, with modules, I would argue that GOPATH is becoming less and less a part of the Go development experience. If go install placed binaries in ~/.local/bin by default instead, it would be more in line with the way other local installation tools work and wouldn't require users to update their $PATH at all on some distributions. If we want to keep $GOPATH/bin, perhaps the tool could put a symlink in ~/.local/bin instead.

I can think of a few reasons why this might not be a good idea:

What about other platforms, like Windows? I don't know if there's a place in all operating systems where user-installed binaries are supposed to be installed. It could be argued that the current approach is a better cross-platform default.

Can't this already be achieved by setting $GOBIN? Sure. I still think there's value in having the best possible default, but having $GOBIN as an option makes this discussion less important.

Is this worth the confusion that changes like this inevitably create? Maybe not. For those of us that use Go daily and already have $GOPATH/bin in our $PATH, this may seem especially frivlious. I think a change like this benefits those who don't develop in Go the most, and non-Go developers will (probably) always outnumber Go developers :)

I'm curious to hear everyone's thoughts.

[Randall O'Reilly]

It would be great if there were a universal standard location in the user's $HOME directory that is already on the PATH, because that always trips up new users when starting to use a CLI.

But that does not appear to be the case on the mac -- this seems to be what a default user gets, at least on my system: /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/Library/Apple/usr/bin

I didn't even know about ~/.local until this email, and I was a longtime linux user prior to mostly using a mac. Windows is always different.

Anyway, given those issues, probably better to stick with the current default like you say..

- Randy

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0c4x5nW80jVehUs666iv%2B_9xp0frEudZH1u5zBHEm%2BjQ%40mail.gmail.com.

[Fuzzy Fabricator]

On Tuesday, July 13, 2021 at 9:50:25 PM UTC-7 rcore...@gmail.com wrote:

It would be great if there were a universal standard location in the user's $HOME directory that is already on the PATH, because that always trips up new users when starting to use a CLI.

But that does not appear to be the case on the mac -- this seems to be what a default user gets, at least on my system: /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/Library/Apple/usr/bin

It doesn't include ~/go/bin, either. We shouldn't be using that then? Also, while macOS is a Unix, it should not be treated as representative of the ecosystem.

 

I didn't even know about ~/.local until this email, and I was a longtime linux user prior to mostly using a mac. Windows is always different.

It's been around for at least a decade. It's part of the freedesktop.org standard hierarchy[0], and notwithstanding some distributions being extremely slow on the uptick. Python's PEP 370[1] from 2008 specifies it - and as a result, pip has been installing to this directory for years, including on macOS.

[0] https://www.freedesktop.org/software/systemd/man/file-hierarchy.html#Home%20Directory

[1] https://www.python.org/dev/peps/pep-0370/

 

Anyway, given those issues, probably better to stick with the current default like you say..

The current default is a strange, non-standard artifact of a dead design that's doing no one any good, least of all newcomers to Go or non-developers just trying to get something installed according to the instructions.

 

[Axel Wagner]

FWIW, ~/.local/bin is not in my path, on Fedora. Though I can, of course, change that. And while macOS might not be treated as representative of the unix ecosystem, it *definitely* should be considered part of the Go ecosystem. It does weaken the argument of ~/.local/bin being "the standard install directory".

I'm not opposed to changing the default install location, but we should have an answer for all platforms. And I think as long as GOPATH exists defaulting to something else seems strange. Setting GOPATH should be a signal that the user is at least aware of the Go conventions. People who want to change the install location can always set GOBIN as well.

And FWIW, I know that we have decided to abandon GOPATH, but it does make me sad. And it's something I'm dearly missing as a newcomer to *other* languages. Having a single environment variable and the guarantee that anything related to that new language is in that single directory - can thus be pruned easily when I'm done experimenting, got into a screwed up state or is guaranteed to have the answer when I'm wondering "what is making $language_tool behave this way?" just seems like a very good idea to me which every language should adopt. But oh well, I know that GOPATH is dying, so I'll have to live with it, I guess.

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/8c3b97c6-5b06-4790-a504-1b2ef7e83fc0n%40googlegroups.com.