Skip to content
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

x/dl/version: installer shouldn't create a new subdirectory of $HOME #26520

Open
RalphCorderoy opened this issue Jul 21, 2018 · 14 comments

Comments

@RalphCorderoy
Copy link

commented Jul 21, 2018

@andybons sent an email to golang-dev yesterday, subject 'Go 1.11 Beta 2 is Released'.
The instructions included

If you have Go installed already, the easiest way to try go1.11beta2
is by installing it using the go command:
$ go get https://golang.org/dl/go1.11beta2
$ go1.11beta2 download

These fail with Arch Linux's go 2:1.10.3-1 package.

$ go get https://golang.org/dl/go1.11beta2
package https:/golang.org/dl/go1.11beta2: "https://" not allowed in import path
$

Removing the `https://' worked. It then matches the comment in https://go.googlesource.com/dl/+/master/go1.11beta2/main.go

Please consider warning that 'go1.11beta2 download' will install to
$HOME/sdk/go1.11beta2 as some folks, me included, won't appreciate new
top-level $HOME directories. Altering $HOME for the run of 'go1.11beta2
download' avoided this on Unix, and it looks like similar is possible on other
platforms.

(Opened issue as requested by Andy in private email.)

@bcmills

This comment has been minimized.

Copy link
Member

commented Jul 23, 2018

There are two separate issues here, I think. One is that the email template we used was wrong; I've updated our release docs with a fix. That leaves the install directory issue, for which I will retitle this issue.

@bcmills bcmills changed the title dl: go1.11beta2 release email has faulty go get instruction dl: installer shouldn't create a new subdirectory of $HOME Jul 23, 2018

@bcmills

This comment has been minimized.

Copy link
Member

commented Jul 23, 2018

I agree that $HOME/sdk is a strange place to put the binary by default. @bradfitz chose it in https://golang.org/cl/34385, on the theory that many users already have a $HOME/sdk directory.

I do not have such a directory, and frankly I find it pretty surprising too: when I install per-language SDKs, I usually put them in ${HOME}/${NAME_OF_SDK}, like ~/go/, with symlinks in ~/bin if I don't want to include the whole install directory in $PATH.

I would argue that $GOBIN (default $GOPATH/bin) is a better default for Go users in general, since we need that directory to exist anyway and its use is already documented.¹

¹https://tip.golang.org/cmd/go/#hdr-GOPATH_environment_variable

(CC @andybons @FiloSottile @dmitshur)

@bcmills bcmills added this to the Unreleased milestone Jul 23, 2018

@FiloSottile

This comment has been minimized.

Copy link
Member

commented Jul 23, 2018

+1 on not liking $HOME/sdk, but I expect my $GOBIN to hold binaries, not whole trees. $GOPATH/sdk makes the most sense to me, even if it ends up being back to $HOME/sdk for me).

@bradfitz

This comment has been minimized.

Copy link
Member

commented Jul 23, 2018

$GOPATH is going away, so let's not overload that and give it new reasons to exist.

@RalphCorderoy

This comment has been minimized.

Copy link
Author

commented Jul 24, 2018

If go1.11beta2/bin/go and everything else don't care where they are, using argv[0] to hone in, then why not insist the user state the location with go1.11beta2 download $root.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Jul 24, 2018

@RalphCorderoy, this is supposed to be the easy way to install Go. No required arguments.

If people feel strongly that there be an optional flag to set the location, maybe. But then you have to store its location somewhere in a known location (probably in $HOME/.config, for which we don't have a helper like https://tip.golang.org/pkg/os/#UserCacheDir) so the "go1.N" binary can find it.

So I'm kinda meh on this bug. The tool is opinionated for simplicity. If you don't like its opinions, install it the traditional way wherever you like? shrug

@bcmills

This comment has been minimized.

Copy link
Member

commented Jul 24, 2018

Perhaps we should use $XDG_DATA_HOME¹ instead?

That seems to be the standard place to stuff long-lived data files that the user otherwise doesn't want to think about.

¹https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html

@bradfitz

This comment has been minimized.

Copy link
Member

commented Jul 24, 2018

And for Mac and Windows? $HOME/.local/share isn't idiomatic on those platforms. Mac would be ~/Library/ something. And Windows surely has something else.

But even on Unix, IMO it's kinda gross to put large files in dot directories. But I suppose we already do that for ~/.cache. I suppose I'm neutral on XDG_DATA_HOME.

@bcmills

This comment has been minimized.

Copy link
Member

commented Jul 24, 2018

IMO it's kinda gross to put large files in dot directories

I would argue that it's kinda gross to put large files any place the user didn't specify explicitly, except perhaps a subdirectory of the current working directory (which go1.11beta2 download presumably can't use because that might be inside $GOPATH/src). But maybe I'm old-fashioned that way?

And Windows surely has something else.

Presumably %ProgramFiles%\go1.N, or perhaps %APPDATA%\Local\go1.N? (@alexbrainman might have a suggestion.)

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Jul 25, 2018

I am not really an expert in this area, but

Presumably %ProgramFiles%\go1.N,

I would say that normal users are not allow to write there. So you need to be admin to be able to do that.

or perhaps %APPDATA%\Local\go1.N

Maybe. Except I do not have %APPDATA%\Local directory on my computer:

c:\>set | grep appdata -i
APPDATA=C:\Users\Alex\AppData\Roaming
LOCALAPPDATA=C:\Users\Alex\AppData\Local
...
c:\>

and

c:\>dir %APPDATA%
 Volume in drive C has no label.
 Volume Serial Number is 9012-A870

 Directory of C:\Users\Alex\AppData\Roaming

13/05/2018  11:44 AM    <DIR>          .
13/05/2018  11:44 AM    <DIR>          ..
23/06/2017  06:43 PM    <DIR>          Adobe
11/02/2018  04:51 PM    <DIR>          Docker
02/07/2017  01:26 PM    <DIR>          Fuji Xerox
23/06/2017  06:59 PM    <DIR>          Google
23/09/2017  10:25 AM    <DIR>          Macromedia
29/08/2017  05:15 PM    <DIR>          Notepad++
23/06/2017  06:49 PM    <DIR>          Skype
...

Alex

@RalphCorderoy

This comment has been minimized.

Copy link
Author

commented Jul 25, 2018

Regarding $XDG_DATA_HOME, it's analogous to /usr/share, thus its default of $HOME/.local/share, and things reading from it are meant to also continue the search through the colon-separated paths in $XDG_DATA_DIRS. My $XDG_DATA_HOME does have a few executables, typically 'contrib' scripts.

The 612 MiB go1.11beta2 dwarfs the 1-2 MiB directories in $XDG_DATA_HOME here, though size isn't a criteria in the spec. It's content doesn't change, but I suppose it's not a .cache because work is required to bring it back after delete.

The audience is small. Would an optional $GOSDK to override the use of homedir()/"sdk" in version.go be acceptable? (I'd have it set to outside the area that's backed up.)

@bradfitz

This comment has been minimized.

Copy link
Member

commented Jul 25, 2018

Would an optional $GOSDK to override the use of homedir()/"sdk"

I'm neutral. I'll let others here decide.

@RalphCorderoy

This comment has been minimized.

Copy link
Author

commented Jul 25, 2018

One more thought on $XDG_DATA_HOME, the user's version of /usr/share, http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA is it seems to be for architecture-independent files, e.g. a $HOME can be mounted on various architectures, just like /usr/share, that's the reason the latter is called 'share'.

Rust describes it that way, https://docs.rs/xdg/2.0.0/xdg/struct.BaseDirectories.html and the executables under mine are scripts rather than ELFs.

@dmitshur dmitshur changed the title dl: installer shouldn't create a new subdirectory of $HOME x/build/cmd/release: installer shouldn't create a new subdirectory of $HOME Sep 25, 2018

@gopherbot gopherbot added the Builders label Sep 25, 2018

@mvdan

This comment has been minimized.

Copy link
Member

commented Jan 10, 2019

I too find it surprising that my home directory was polluted. I agree that we shouldn't tie it to GOPATH directly. GOCACHE (the build cache) exists so one can throw it away whenever, as rebuilding it tends to not be too expensive. So anywhere under GOCACHE is likely not a good idea either.

cmd/go already has a solution for this - the directory where the module cache is placed. Right now, that happens to be GOPATH/pkg/mod, but I presume it would get moved somewhere else once GOPATH is gone.

Why not put the release download cache there too? For example, we already have pkg/mod/cache/vcs, so one could imagine pkg/mod/cache/sdk. This might require x/dl to be able to ask cmd/go something like "where is the module cache?", but I presume we can make that work.

The only other complication is that the sdk download cache might get large, and it would be somewhat hidden. A solution could be for each goX.Y wrapper program to have a very simple goX.Y uninstall command, which would delete the cached SDK, and perhaps its own binary too.

@bradfitz bradfitz changed the title x/build/cmd/release: installer shouldn't create a new subdirectory of $HOME x/dl/version: installer shouldn't create a new subdirectory of $HOME Jan 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.