Go one-line installer

[Steve Francia]

Greetings Gophers,

I've been working on a "one line installer" for Go with Jess Frazelle and Chris Broadfoot and we think it's ready to share a bit more broadly.

The installer is designed to both install Go as well as do the initial configuration of setting up the right environment variables and paths.

It will install the Go distribution (tools & stdlib) to "/.go" inside your home directory by default.

It will setup "$HOME/go" as your GOPATH. 

If Go is already installed via this installer it will upgrade it to the latest version of Go.

Currently supported systems:

  linux, darwin, windows / amd64, 386 / bash, zsh, powershell

Usage

Windows Powershell:

(New-Object System.Net.WebClient).DownloadFile('https://get.golang.org/installer.exe', 'installer.exe'); Start-Process -Wait -NonewWindow installer.exe; Remove-Item installer.exe

Shell (Linux/macOS/Windows):

curl -LO https://get.golang.org/$(uname)/go_installer && chmod +x go_installer && ./go_installer && rm go_installer

As we discovered developing this, installers are really all edge cases. We're certain we've not found many of them. 

Our goal is that this becomes the primary mechanism to install Go. 

To do that, we need your help testing, improving and fixing it. 

The source can be found at https://go.googlesource.com/tools/+/master/cmd/getgo/

If you find any issues please report them on Github https://github.com/golang/go/issues/new?title=tools/cmd/getgo:

Thanks,

Steve

[Val]

Hello Steve, that looks very promising, thank you so much!

I just tried on GCE, here is a gist.
Possible quirk :

$ go version

go: cannot find GOROOT directory: /usr/local/go
$ go doc fmt
go: cannot find GOROOT directory: /usr/local/go
$ go get github.com/gorilla/mux
go: cannot find GOROOT directory: /usr/local/go

Note that I didn't try to sudo anything.

Questions:
- is it recommanded to set the GOPATH variable, even since 17262 and go 1.8 seem to regard ~/go as a cromulent default?
- might it be possible to avoid to extra step "One more thing! ... ... ... or open a new shell prompt", by sourcing everything needed? Something like
curl -LO https://get.golang.org/$(uname)/go_installer_script && source go_installer_script

This one-liner project will bring all of us command-line users a super-nice developer UX, especially when frequently installing Go to new machines :)
Cheers
Valentin

[Florin Pățan]

Hi,

The idea is good but:
- it needs to modify the path to add GOROOT/bin and GOPATH/bin to it
- it should allow for multiple versions of Go to be installed simultaneously (including 1.x.y vs 1.x.z versions)
- it should change the PATH on all three OSes regardless of the shell used, which is the hardest part I guess (as this is the part that trips over most of the people, along with the GOPATH requirement)

Thank you.

[Tyler Compton]

> I was quite happy that the era of executable "installers" died once we
> got package managers.

This seems to come from a purely Linux perspective. I suspect that people who use Linux are quite a bit less likely to benefit from this solution anyway, because most Linux users are used to setting environment variables and installing from tarballs. The era of executable installers has not died on Windows or on Mac.

> If something is to be improved, perhaps the
> quality of packages for various distributions could be improved
> instead. That is what the users want anyway, to use their distro
> package manager.

Trying to improve every distro's Go version is a substantially more difficult problem, and even worse, it's a bureaucratic one. I think it would be a lot more productive to spend that time working on the technical problem of security than giving up and tackling a much harder one.

--
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.
For more options, visit https://groups.google.com/d/optout.

[Steve Francia]

On Tuesday, August 1, 2017 at 7:49:32 PM UTC-4, Florin Pățan wrote:

Hi,

The idea is good but:
- it needs to modify the path to add GOROOT/bin and GOPATH/bin to it

It does. If it didn't do this you've found a bug. Please report it.

- it should allow for multiple versions of Go to be installed simultaneously (including 1.x.y vs 1.x.z versions)

Out of scope for this tool, though it can do it with passing along flag arguments

- it should change the PATH on all three OSes regardless of the shell used, which is the hardest part I guess (as this is the part that trips over most of the people, along with the GOPATH requirement)

There's no such thing. ENV variables are shell specific. The PATH is defined in the shell initialization script on *nix. It literally tells the shell what directories to look in. On Windows it does this as the PATH is set by an OS call directly. Unfortunately bash on Windows ignores it.  

Thank you.

[Steve Francia]

Please file an issue with this information and as much details as you can. 

On Tuesday, August 1, 2017 at 5:38:24 PM UTC-4, Val wrote:

Hello Steve, that looks very promising, thank you so much!

I just tried on GCE, here is a gist.
Possible quirk :

$ go version

go: cannot find GOROOT directory: /usr/local/go
$ go doc fmt
go: cannot find GOROOT directory: /usr/local/go
$ go get github.com/gorilla/mux
go: cannot find GOROOT directory: /usr/local/go

Note that I didn't try to sudo anything.

Questions:
- is it recommanded to set the GOPATH variable, even since 17262 and go 1.8 seem to regard ~/go as a cromulent default?
- might it be possible to avoid to extra step "One more thing! ... ... ... or open a new shell prompt", by sourcing everything needed? Something like
curl -LO https://get.golang.org/$(uname)/go_installer_script && source go_installer_script

We can't source the binary, but we may be able to source the shell initialization file.  

[Dan Kortschak]

Thanks.

[Aram Hăvărneanu]

> most Linux users are used to setting environment variables and
> installing from tarballs.

No, most Linux users are used to installing from package managers.
Unless you were referring to installing Go in particular, where I
conjecture that most Linux users who don't use some package manager
to install Go, are installing from source.

> The era of executable installers has not died on Windows or on Mac.

I can't speak for Windows, but macOS (or OS X, or Mac OS X) never
had executable installers like Windows had. It had .pkg installers,
which are not the same thing at all, and even those are pretty rare
today, restricted mostly to software that has to install kernel
components and such. Most programs install by copying from zip/dng
files or by installing from the App Store (a package manager).

Mac users most certainly aren't used to executable installers.

> I think it would be a lot more productive to spend that time working
> on the technical problem

The problem you are mentioning is the halting problem. There is no way
reliably set configuration variables without solving the halting
problem.

I do not consider time spent on the halting problem to be productive
time. Sorry.


--
Aram Hăvărneanu

[Henrik Johansson]

At home on my Arch i really prefer pacman for everything and only as a last resort do I ever exec any curlable installer.

The problem is usually that they don't get properly updated and the packagemanager anyway pulls in Go since it is a dependency for

something else and it is a mess with two or more installations.

On my work Mac I have only ever installed one thing, "Oh my zsh", using curl everything else have been installers or Homebrew.

My 2¢

I can see this to be beneficial when you pull up a VM and wants to quickly and easily install but for Linux in general I am not sure.

[Florin Pățan]

I speak from the experience of trying to help people get Go running on Linux, macOS and Windows, this is a terribly frustrating step and unknown for most of them.

Please don't dismiss this based on what you think but rather on actual facts. I can show you countless questions that come up in Slack on: how do I install this and people being frustrated with the setup process.

[Florin Pățan]

On Wednesday, August 2, 2017 at 3:14:07 AM UTC+1, Steve Francia wrote:

On Tuesday, August 1, 2017 at 7:49:32 PM UTC-4, Florin Pățan wrote:

Hi,

The idea is good but:
- it needs to modify the path to add GOROOT/bin and GOPATH/bin to it

It does. If it didn't do this you've found a bug. Please report it.

I'll have a look at it again. Thank you.

 

- it should allow for multiple versions of Go to be installed simultaneously (including 1.x.y vs 1.x.z versions)

Out of scope for this tool, though it can do it with passing along flag arguments

If you want this to become the de facto way to install Go, then it's a must, not out of scope.

Many people want to test a newer version of Go before switching to it, being forced to run a single version of Go because of this "installer" will not make anyone happy and will only serve to complicate things further.

 

- it should change the PATH on all three OSes regardless of the shell used, which is the hardest part I guess (as this is the part that trips over most of the people, along with the GOPATH requirement)

There's no such thing. ENV variables are shell specific. The PATH is defined in the shell initialization script on *nix. It literally tells the shell what directories to look in. On Windows it does this as the PATH is set by an OS call directly. Unfortunately bash on Windows ignores it.  

I meant, it has to provide support for changing the bash.rc, zsh.rc and other popular shells.

 

Thank you.

 

[Jan Mercl]

On Wed, Aug 2, 2017 at 12:27 PM Florin Pățan <flori...@gmail.com> wrote:

> I speak from the experience of trying to help people get Go running on Linux, macOS and Windows, this is a terribly frustrating step and unknown for most of them.

Please share what's frustrating and not clear about the step-by-step instructions, so they can be improved.

--

-j

[Florin Pățan]

I would never put anyone to the trouble of compiling Go themselves, so it's not clear why you are suggesting that. I also don't do that myself and cannot see the value on doing it. Go has installers available for Windows/macOS and a tarball for Linux, already precompiled and ready to Go (pun intended), why would I spend the time compiling Go myself?

Back on track.

People have problems with following this page: https://golang.org/doc/code.html . I don't know how it can be improved because I cannot understand the problem myself. Whenever I explain it to those that fail to read, it suddenly becomes clear and following the same steps there makes it magically work. And it's even funnier when I solve it for the people working on macOS because I never used that OS but people that have been using it for years seem unable to change environment variables :)

Maybe simple, clear, videos on how to set GOPATH, PATH and so on on the various operating systems would help as it's usually easier for anyone to just follow the instructions provided in a visual way (but I don't have any data/facts to back this up).

[Jan Mercl]

On Wed, Aug 2, 2017 at 12:47 PM Florin Pățan <flori...@gmail.com> wrote:

> I would never put anyone to the trouble of compiling Go themselves, so it's not clear why you are suggesting that.

From where comes the assumption that it's a trouble? I was not suggesting anything, but while we are at it, I think that installing from sources is by far the easiest way how to install Go. Precompiled binaries are inevitably depending on assumptions about the target system that can never be true across everyone's box - even when targeting the proper arch/platform/distro and release (and then you have to maintain a lot of targets). And if the assumptions don't hold, then that's what I'd call frustrating, provided it's usually not immediately clear where the problem is because there was no compiling/buildind/testing peformed locally making it much easier to figure out what went wrong.

> I also don't do that myself and cannot see the value on doing it.

Well, by definition you can't if you haven't tried. Anyway, above quoted says it's a trouble. Why?

> Go has installers available for Windows/macOS and a tarball for Linux, already precompiled and ready to Go (pun intended), why would I spend the time compiling Go myself?

To avoid the frustration and confusion you are talking about? I have always installed Go from sources and I never experienced any frustration when doing that (modulo me not reading or following the instructions and similar cases of being silly.)

--

-j

[roger peppe]

When I've suggested that people install Go from source, I have encountered
problems because go1.4 no longer compiles from source on some platforms.

[Igor Maznitsa]

I also had interest for such installer about year ago and developed mvn-golang plugin (which can download and install go sdk and tune environment during build process) but it works in maven environment of course

[mhh...@gmail.com]

Hi,

As you at this kind of work, have you considered a reliable one-liner to install dependencies ?

I got that own, just today, from a gae repo (?), anyways here it is,

go get -u -v $(go list -f '{{join .Imports "\n"}}{{"\n"}}{{join .TestImports "\n"}}' ./... | sort | uniq | grep -v golang-samples)

Problem is, it did not quiet work for me when i put that into my travis :x
https://travis-ci.org/mh-cbon/dht/jobs/260206514

even when i restart the job.

Do you have any ideas how to fix that ?


thanks

On Tuesday, August 1, 2017 at 9:42:00 PM UTC+2, Steve Francia wrote:

[Tyler Compton]

> No, most Linux users are used to installing from package managers.

I don't know if that's true. Many popular distributions provide undesirably out-of-date versions of common tools and require users to use other means to install them. But both of our assertions are valueless without data, so it may not be worth discussing.

> Unless you were referring to installing Go in particular, where I
> conjecture that most Linux users who don't use some package manager
> to install Go, are installing from source.

I would have thought users would be more likely to reach for the pre-built versions of Go, but again, we need data.

> I can't speak for Windows, but macOS (or OS X, or Mac OS X) never

> had executable installers like Windows had.

Fair enough, I admit I don't know a lot about the Mac sphere.

> The problem you are mentioning is the halting problem. There is no way

> reliably set configuration variables without solving the halting
> problem.
> I do not consider time spent on the halting problem to be productive
> time. Sorry.

I was referring to the problem of security, not the problem of configuration variables. Certainly some of the security concerns with this project can be addressed without solving the halting problem.

--