Leave the $GOPATH alone please

[sethgrid]

I don't want my $GOPATH changed when I switch to a different version of Go.

$ go version
> go version go1.4.3 darwin/amd64
$ echo $GOPATH
> /Users/sethammons/workspace/go
$ gvm use 1.6
> Now using version go1.6
$ echo $GOPATH
> /Users/sethammons/.gvm/pkgsets/go1.6/global
$ gvm use 1.5
> Now using version go1.5
$ echo $GOPATH
> /Users/sethammons/.gvm/pkgsets/go1.5/global

[xprazak2]

+1, related to these comments

[TakenPilot]

I'm a bit confused by this request. Isn't $GOPATH how gvm switches versions of go?

[xprazak2]

As explained in this SO question, $GOPATH points to your workspace (where your code is located), and $GOROOT specifies where to look for go. $GOPATH gets changed each time you switch to different go version (as demonstrated above) which is a major drawback when you want to test your code against multiple go versions.

[TakenPilot]

Oh, that makes sense. Thanks for answering my question!

[StabbyCutyou]

I'd love to see this change as well.

It's very inconvenient to switch versions, and have to re-download everything. A better solution is to have a static GOPATH where things live forever, and gvm just switches out which go is being used to run/compile them.

Any official word on if this is something you'd consider supporting?

[deanxorr]

👍 also, this can make minor version updates a bit tedious. As it is I use a custom $GOPATH for all my projects and have to export that every time I use gvm to switch to get around this behavior

[jbussdieker]

A quick fix would be to delete the GOPATH line from the environment file.

 $ cat ~/.gvm/environments/go1.4
 export GVM_ROOT; GVM_ROOT="/Users/josh/.gvm"
 export gvm_go_name; gvm_go_name="go1.4"
 export gvm_pkgset_name; gvm_pkgset_name="global"
 export GOROOT; GOROOT="$GVM_ROOT/gos/go1.4"
-export GOPATH; GOPATH="$GVM_ROOT/pkgsets/go1.4/global"
 export GVM_OVERLAY_PREFIX; GVM_OVERLAY_PREFIX="${GVM_ROOT}/pkgsets/go1.4/global/overlay"
 export PATH; PATH="${GVM_ROOT}/pkgsets/go1.4/global/bin:${GVM_ROOT}/gos/go1.4/bin:${GVM_OVERLAY_PREFIX}/bin:${GVM_ROOT}/bin:${PATH}"
 export LD_LIBRARY_PATH; LD_LIBRARY_PATH="${GVM_OVERLAY_PREFIX}/lib:${LD_LIBRARY_PATH}"
 export DYLD_LIBRARY_PATH; DYLD_LIBRARY_PATH="${GVM_OVERLAY_PREFIX}/lib:${DYLD_LIBRARY_PATH}"
 export PKG_CONFIG_PATH; PKG_CONFIG_PATH="${GVM_OVERLAY_PREFIX}/lib/pkgconfig:${PKG_CONFIG_PATH}"

[codepushr]

It might make sense to have separate workspaces depending on the go version but as far as I understand the Go dev team is working backwards-compatible which makes this a little obsolete?

My biggest issue is symlinking my projects to the new GOPATH everytime I change to a new Go version, so I agree having one place is simply more convenient.

[chmike]

+1 This is a serious problem with gvm. Switching go version can be achieved by symbolic link changes instead of GOPATH value change.

[frankscholten]

+1

[danihodovic]

@jbussdieker Is it possible to upstream the change you propose in #189 (comment)?

[osdiab]

+1

[Random-Liu]

+1

[dancompton]

+100

[dancompton]

In fact, is there existing fork for this?

[danihodovic]

+1, an alternative solution is to source gvm first and declare GOPATH later in your .zlogin/.bashrc

source ${HOME}/.gvm/scripts/gvm
export GOPATH=$HOME/repos/go_pkg
export PATH=$PATH:$GOPATH/bin

[chmike]

What I do is the following. I don't know if it's the right way to do it, but it works.
I append my repo path to the GOPATH generated by gvm:

source ${HOME}/.gvm/scripts/gvm
export GOPATH=${GOPATH}:$HOME/repos/go_pkg

With this, I get a fresh empty gvm pkg dir when I install a new go version. I have to get again the package I need. This avoids the accumulation of old packages I don't use anymore or package not compiled with the latest compiler.

The packages I create in my repo are stored in my repo/pkg directory and are found when importing them.

I wish there was a build command that could issue the go get command automatically.

[dancompton]

I would advocate for less complexity, not more. I suppose the fundamental question becomes: does GVM stand for GOPATH version manager or Go version manager?

[e-nikolov]

@dan-compton I made a fork at https://github.com/e-nikolov/gvm and commented out the code that dealt with managing the $GOPATH. Seems to work for me.

[guiguan]

Looks like the author wanted us to use gvm pkgset as well as gvm linkthis to manipulate $GOPATHs

[guiguan]

You can probably use gvm pkgenv to setup your own $GOPATH

[e-nikolov]

Is it possible to add a custom global pkgset? I didn't see a way to do that and having to add a new pkgset each time I upgrade to a new version of golang seems like too much effort.

Also is it possible to set a pkgset as default? I only saw this is possible for go versions.

[guiguan]

@e-nikolov you are right, there is no global pkgset, nor does gvm have a command to migrate them into new go versions. However, we could migrate a pkgset, saying from go1.9.1 to go1.9.2, like this:

gvm install go1.9.2
mv ~/.gvm/pkgsets/go1.9.1/${PKGSET_NAME} ~/.gvm/pkgsets/go1.9.2
mv ~/.gvm/environments/go1.9.1@${PKGSET_NAME} ~/.gvm/environments/go1.9.2@${PKGSET_NAME}
vim ~/.gvm/environments/go1.9.2@${PKGSET_NAME} # and replace all 1.9.1 with 1.9.2

gvm use 1.9.2 --default
gvm pkgset use ${PKGSET_NAME} --default

[doapp-ryanp]

golang noob here. Why is $GOPATH modified by gvm in the 1st place? golang docs say the convention is GOPATH=$HOME/go.

[refs]

FWIW I use direnv, so whenever I switch versions I override GOPATH for my current working directory

[fgblomqvist]

What @jbussdieker said is correct but not enough.

You need to:

• Comment out/remove that line in all of the (probably generic) scripts in ~/.gvm/environments
  • Such as go1.4, go1.11, system, default etc.
  • I'd leave the ones that specify a packageset, such as go.11@global since it makes sense to actually switch package sets if you explicitly specify it
• Comment out/remove the line unset GOPATH (line 4 for me) in ~/.gvm/scripts/gvm-default

Now when you restart your terminal session you will finally be back to whatever GOPATH you orginally set (e.g. in .bashrc), and switching go versions won't impact it. Just remember to comment out/remove those lines in any new scripts created (when installing new go versions and so forth). The alternative is to use @e-nikolov's fork.

[ihgann]

@fgblomqvist Thanks for this - would still love to see an official direction from moovweb on this. gvm is an almost-necessary tool I use regularly, but I still dread upgrading go versions due to this issue.

[yidane]

I changed all scripts in ~/.gvm/environments and then set ALL GOPATH to default GOPATH which I want, and It fixed.

[BenKnigge]

Hello, I've recently taken over as maintainer of this project and this is an issue that I would like to address in the near future. Any suggestions regarding the best way to approach this?

[fgblomqvist]

Appreciate the attention! I'd suggest putting this changing of GOPATH behind a config option somewhere. Depending on if you want to keep backwards-compatibility or not (and release a new major version), I suppose it's up to you whether you want to make it on by default or not, but I am sure that most people who are new to gvm would expect gvm to not switch the GOPATH.

[pengisgood]

Any updates on this feature?

[fgblomqvist]

@BenKnigge any updates? The simplest path forward is imo to just remove all the switching and then bump major version. Shouldn't take more than like 30 min. Lmk if you want a PR.

[DavudSafarli]

2021. any update?

[jbussdieker]

FWIW pkgsets were an abandoned concept. It's been a long time since I've worked in this area but what @fgblomqvist suggests sounds like the best path forward.

[JohnRusk]

Almost another year has gone by on this. Any update, or at least a recommended workaround?

[e-nikolov]

I use asdf because it's nice to have a single version manager for all languages.

[JohnRusk]

FWIW, the workaround I'm currently using is as follows (based on @chmike's comment above).

In .bashrc

source "$HOME/.gvm/scripts/gvm"        # start Go version manager
source "$HOME/.local/setupGvmWrapper"  # force use of my wrapper script
gvm use go1.17.5  # default to something, so that Go is ready to go on boot

in .local/setupGvmWrapper

#!/bin/bash

#dot source this script AFTER dot sourcing the real GVM

#Create a function real_gvm that is the same as the original gvm function (from Go Version Manager)
eval real_"$(declare -f gvm)"

#now (re)define gvm function to have my extra processineg
gvm() {
  echo "My GVM wrapper"
  real_gvm "$@"

  # realGvm will set GOROOT as I want it to be.
  # It will also set GOPATH in way that I don't really want, so after initializing
  # GVM, I use the workaround listed here
  # https://github.com/moovweb/gvm/issues/189#issuecomment-311616290
  # to append my own go dir. (Named go-mine below)

  if [[ "$GOPATH" =~ "$HOME/go-mine" ]]; then
    echo "Go path already contains $HOME/go-mine"
  else
    export GOPATH=${GOPATH}:$HOME/go-mine
    echo "GOPATH=$GOPATH"
  fi
}

I don't know if that's the right or best way, but it's what I'm using for now.

[tosan88]

👋 Any updates on this feature?