GVM workflow for newbies

[leebrooks0]

As a Go newbie, I am battling to get my workflow right.

I have installed Go 1.2 as per the GVM instructions.

I want to be able to have my Go projects eg. ProjectA and ProjectB in a directory say ~/side_projects.

What I have tried so far is outlined below:

mkdir ProjectA
cd ~/side_projects/ProjectA
gvm pkgset create --local
gvm pkgset use --local

$GOPATH now returns

/home/lee/side_projects/ProjectA:/home/lee/side_projects/ProjectA/.gvm_local/pkgsets/go1.2/local:/home/lee/.gvm/pkgsets/go1.2/global

I then created a hello-world.go and a test-package.go file.

hello-world.go:

package main

import (
    "test_package"
    "fmt"
)

func main() {
    fmt.Println(test_package.HelloWorld())
}

test-package.go

package test_package

func HelloWorld() string {
    return "Hello world"
}

go run hello-world.go complained so I had to move all the code into a src directory, and then place test_package.go into a directory with the same name, and then things worked as expected

Then I installed Revel via go get github.com/robfig/revel, and the problem is best explained with a screenshot:

Here is /home/lee/side_projects/ProjectA

Here is /home/lee/side_projects/ProjectA/src

The third party packages are now mixed with my own, and now i am pretty confused.

1. Can't the third party packages go into the .gvm-local folder?
2. If Go projects require src and pkg directories, where do I place my application code? Directly in src? I don't want my code sitting in the same directory as external libraries as it currently happening.
3. Where do I place my git repo? Directly in src, or in ProjectA, and add pkg to gitignore? (Assuming I can get the external packages to go into .gvm-local)?

[mdayaram]

Oh dear, this might actually be a bug in GVM.

The reason why external libraries are being place in the same directory as your code is because your GOPATH has that directory listed first. go get will automatically place fetched packages onto the first path in your GOPATH.

It looks like GVM might have to change the order of the paths in GOPATH when using pkgsets.

[mdayaram]

Hmm...however, the first path is also used for installation and the pkg and bin directories when running things like go install and whatnot. For those, you probably want the location to be your programming root.

Hmm, this is a tricky one...

[leebrooks0]

I can safely say that I know considerably more about GOPATHs after reading
the golang docs than when I wrote this :) Still don't really know exactly
what is cutting here with pkgset etc. So I am learning by trying out GVM
and seeing what happens :)

On Thu, Jan 2, 2014 at 10:20 PM, Manoj Dayaram notifications@github.comwrote:

Oh dear, this might actually be a bug in GVM.

The reason why external libraries are being place in the same directory as
your code is because your GOPATH has that directory listed first. go getwill automatically place fetched packages onto the first path in your
GOPATH.

It looks like GVM might have to change the order of the paths in GOPATHwhen using
pkgsets.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/46#issuecomment-31481232
.

[ghost]

I've confirmed I'm having the same problem.

$ gvm pkgset create --local
gvm pkgset use --local
Now using version go1.8.3 in local package set
Local GOPATH is now /Users/wes/projects/ocean-currents/.gvm_local
$ echo "$GOPATH"
/Users/wes/projects/ocean-currents:/Users/wes/projects/ocean-currents/.gvm_local/pkgsets/go1.8.3/local:/Users/wes/.gvm/pkgsets/go1.8.3/global

This issue is really old. Are pkgsets basically unusable at this time?

[ihgann]

@wesm-outreach Yes, I'm still facing this same issue and it's essentially caused me to drop pkgset and exclusively use my own GOPATH.

In my .zshrc, I do:

[[ -s "${HOME}/.gvm/scripts/gvm" ]] && source "${HOME}/.gvm/scripts/gvm"
export GOPATH=/code/go
export PATH=$PATH:$GOPATH/bin

I use direnv for my repos, and in that I use:

CUR_GOPATH=${GOPATH}
gvm use go1.11.1
export GOPATH=${CUR_GOPATH}

whereas ideally I could do:

gvm use go1.11.1
gvm pkgset use --local

Unfortunately until this is resolved I'm basically sticking to this pattern.