How to manage multiple versions of Go?

[st ov]

Do you use gvm? https://github.com/moovweb/gvm

Is there a simpler way?

How do you avoid conflicts with Homebrew? Should I not run 'brew install go'?

[Christoph Berger]

Thanks to the Go 1 Compatibility Promise, it was never a problem for me to always use the latest Go version (via Homebrew, BTW, which keeps my Go installation up-to-date with next-to-zero effort). 

If I ever have the need to use an older version, I'd probably use Docker for that. 

Advantages of using Go within a Docker container:

* No accidental mixing of Go versions

* No multi-GOPATH hassle

* Can be removed cleanly when not needed anymore.

[st ov]

Could you go into a bit more detail on how you would setup a local docker container for your Go development?

Also how does the following experience relate to the compatibility promise?
https://github.com/moovweb/gvm#background

Thanks!

[buddyspike]

If you want to build with different versions of go, you could play with PATH during build. Perhaps a better option is to use a container with go toolchain pre-configured for each version.

For example

https://hub.docker.com/r/buddyspike/go/~/dockerfile/ 

[Jesper Louis Andersen]

On Sun, Jun 25, 2017 at 4:36 PM Christoph Berger <christoph...@gmail.com> wrote:

Thanks to the Go 1 Compatibility Promise, it was never a problem for me to always use the latest Go version (via Homebrew, BTW, which keeps my Go installation up-to-date with next-to-zero effort). 

That was my first hunch as well, but language compatibility doesn't automatically guarantee implementation compatibility. I'll definitely agree one should strive to make the code work well with the newest Go release always, but there are reasons people doesn't upgrade right away. Reproducible builds is common nowadays and that requires you use the same version of the Go compiler, for instance.

What I tend to do is to use the newest release for building the software (this ensures that the eventual upgrade path is clear). And then let a build system handle the older versions if needed. That way, you can often program yourself out of the problem by mangling PATHs rather than running a complete docker installation.

On the other hand, if you do containerize your world anyhow, that may be the simplest solution. I'm quite partial to either jails (FreeBSD) or Zones (Solaris/Illumos) personally over docker though. 

[Rob Pike]

I just use the shell for this:

% cat bin/go1.4

#!/bin/sh

export GOARCH=amd64

export GOOS=darwin

export GOROOT=/home/r/go1.4  # Note!

export GOBIN=$GOROOT/bin

exec $GOBIN/go "$@"

% 

Then when I want to run Go 1.4 tests, I just say "go1.4 build" instead of "go build".

-rob

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

[Christoph Berger]

> Could you go into a bit more detail on how you would setup a local docker container for your Go development?

One example has been given by buddyspike already.

Two blog articles for getting started:

https://blog.docker.com/2016/09/docker-golang/

https://medium.com/statuscode/golang-docker-for-development-and-production-ce3ad4e69673

>Also how does the following experience relate to the compatibility promise?

https://github.com/moovweb/gvm#background

I cannot comment on this experience as there aren’t any details included. 

I acknowledge that in reality there is no such thing as 100% compatibility. So far, compatibility issues have been no problem for me, but I can only speak for myself. 

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/uAcPk39Tb0I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Christoph Berger]

> Reproducible builds is common nowadays and that requires you use the same version of the Go compiler, for instance.

Agreed. I did not want to imply that *my* experience with Go compatibility must apply to everyone else. 

> On the other hand, if you do containerize your world anyhow, that may be the simplest solution.

I must admit that I silently assumed that Docker is already installed. Having to install Docker first might be prohibitive in some scenarios. OS-native options like those you mentioned can be a good alternative then.

[st ov]

Thanks for all the references and advice.

All the suggested approaches have helped give me sense of how to handle it.

[Igor Maznitsa]

mvn-golang plugin also allows to automate work with multiple versions of Go

[fge...@gmail.com]

You can also 'go get' most go versions and it's quite robust.
https://twitter.com/golang/status/875117556595515392

On Mon, Jun 26, 2017 at 5:17 PM, Igor Maznitsa <rrg...@gmail.com> wrote:
> mvn-golang plugin also allows to automate work with multiple versions of Go
>

> --
> 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

[fge...@gmail.com]

Sorry, I'll correct myself:
godoc.org/golang.org/x/build/version
only handles the listed directories.
Though if for example you copy an existing directory to go1.8.3 and
trivially modify main.go
You'll have this:
C:\>go build golang.org/x/build/version/go1.8.3

C:\>go1.8.3 version
go1.8.3: not downloaded. Run 'go1.8.3 download' to install to
C:\User\loggedinuser\sdk\go1.8.3

C:\>go1.8.3 download
Downloaded 0.0% (15233 / 83369649 bytes) ...
....
Downloaded 97.5% (81312629 / 83369649 bytes) ...
Downloaded 100.0% (83369649 / 83369649 bytes)
Unpacking C:\Users\loggedinuser\sdk\go1.8.3\go1.8.3.windows-386.zip ...
Success. You may now run 'go1.8.3'

C:\>go1.8.3 version
go version go1.8.3 windows/386