Leave the $GOPATH alone please #189

Open
sethgrid opened this Issue Mar 7, 2016 · 24 comments

Comments

Projects
None yet
@sethgrid

sethgrid commented Mar 7, 2016

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

This comment has been minimized.

Show comment
Hide comment

+1, related to these comments

@TakenPilot

This comment has been minimized.

Show comment
Hide comment
@TakenPilot

TakenPilot Mar 30, 2016

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

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

@xprazak2

This comment has been minimized.

Show comment
Hide comment
@xprazak2

xprazak2 Mar 31, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@TakenPilot

TakenPilot Mar 31, 2016

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

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

@StabbyCutyou

This comment has been minimized.

Show comment
Hide comment
@StabbyCutyou

StabbyCutyou Apr 28, 2016

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?

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

This comment has been minimized.

Show comment
Hide comment
@deanxorr

deanxorr Apr 28, 2016

👍 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

👍 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

This comment has been minimized.

Show comment
Hide comment
@jbussdieker

jbussdieker Apr 28, 2016

Contributor

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}"
Contributor

jbussdieker commented Apr 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@codepushr

codepushr Jul 10, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@chmike

chmike Aug 24, 2016

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

chmike commented Aug 24, 2016

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

@frankscholten

This comment has been minimized.

Show comment
Hide comment

+1

@danihodovic

This comment has been minimized.

Show comment
Hide comment
@danihodovic

danihodovic Feb 24, 2017

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

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

@osdiab

This comment has been minimized.

Show comment
Hide comment

osdiab commented May 25, 2017

+1

@Random-Liu

This comment has been minimized.

Show comment
Hide comment

+1

@dan-compton

This comment has been minimized.

Show comment
Hide comment

+100

@dan-compton

This comment has been minimized.

Show comment
Hide comment
@dan-compton

dan-compton Jun 27, 2017

In fact, is there existing fork for this?

In fact, is there existing fork for this?

@danihodovic

This comment has been minimized.

Show comment
Hide comment
@danihodovic

danihodovic Jun 28, 2017

+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

+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

This comment has been minimized.

Show comment
Hide comment
@chmike

chmike Jun 28, 2017

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.

chmike commented Jun 28, 2017

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.

@dan-compton

This comment has been minimized.

Show comment
Hide comment
@dan-compton

dan-compton Jun 29, 2017

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?

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

This comment has been minimized.

Show comment
Hide comment
@e-nikolov

e-nikolov Oct 26, 2017

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

e-nikolov commented Oct 26, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@guiguan

guiguan Oct 30, 2017

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

guiguan commented Oct 30, 2017

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

@guiguan

This comment has been minimized.

Show comment
Hide comment
@guiguan

guiguan Oct 30, 2017

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

guiguan commented Oct 30, 2017

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

@e-nikolov

This comment has been minimized.

Show comment
Hide comment
@e-nikolov

e-nikolov Oct 30, 2017

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.

e-nikolov commented Oct 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@guiguan

guiguan Oct 30, 2017

@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

guiguan commented Oct 30, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@doapp-ryanp

doapp-ryanp Jan 10, 2018

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment