

A simple virtualenv for Go - chuckha
https://github.com/ChuckHa/goenv

======
jerf
I was interested when I saw the project name, but this appears to be:

    
    
        mkdir -p pkg bin src
        export GOPATH="`pwd`"
        export PATH="$GOPATH/bin:$PATH"
    

Only what I typed there is shorter and safer than the committed code.

That's... simple, yes.

[https://github.com/ChuckHa/goenv/blob/master/goenv](https://github.com/ChuckHa/goenv/blob/master/goenv)

~~~
chuckha
Awesome, I won't pretend to be a bash expert. Any interest in opening a PR?

~~~
jerf
Naw, just go ahead and commit that if you like. That's too much easier to be
worth the fork/checkout/commit/push/pull request cycle work in this case.

~~~
olov
Understandable - but it's pretty easy to do small modifications like that
using Github's edit feature. Everything but the editing itself is pretty much
hidden away.

~~~
jerf
Did not know that. Thanks!

------
lotheac
This seems to copy a bad design decision from virtualenv. Please see
[https://gist.github.com/datagrok/2199506](https://gist.github.com/datagrok/2199506)

~~~
chuckha
I implemented the suggestions in this gist on a new branch here:

[https://github.com/ChuckHa/goenv/tree/inve](https://github.com/ChuckHa/goenv/tree/inve)

I'm not sure I like it better though because it unsets $PS1 and other
variables that get set in .bash_profile.

------
jscheel
I'm actually a little confused by go's global approach, which ultimately gives
rise to the myriad of solutions listed in the comments here. Am I missing some
go-centric way of thinking?

~~~
chuckha
I think the documentation about go workspaces is just a simple approach and
it's expected the community will eventually settle on a way to manage this in
a non-global fashion.

I'm guessing everyone wants something slightly different and it would be
pointless for Go to have One Way hence all the alternatives here.

~~~
BarkMore
What makes the recommended approach in the workspace documentation "global"?

------
zackkitzmiller
Very nice. A little while back I wrote something similar for those who use the
fish shell. You can find that here, if you're interested:
[https://github.com/zackkitzmiller/gofish](https://github.com/zackkitzmiller/gofish)
(Pull requests also welcome)

------
lstoll
There's already a `goenv`
[https://github.com/wfarr/goenv](https://github.com/wfarr/goenv), that I've
been using for a bit. Also can do go version management.

~~~
chuckha
Thanks for pointing this out, I hadn't found it.

------
JulianMorrison
The approach we've taken at work is, each project has its own src/pkg/bin tree
under the checked-in root, and we just set GOPATH. Simple and easy.

~~~
2mur
This seems like a very reasonable approach. Thanks!

------
BarkMore
It's too simple. PATH grows with each use of the tool.

~~~
wilmoore
Depends on your perspective. For a tmux or screen user, this would seldom, if
ever, be a concern. Even for those that don't use tmux or screen; why add more
code and complexity to solve what amounts to a (arguable) workflow disfunction
(i.e. endlessly switching projects in a single shell window/pane). I mean, I'm
sure it happens, but this is your trade-off for simplicity.

------
mediocregopher
I'll throw my hat in with all the other contenders in here. I've written a
tool called goat which wraps around the normal go utility and sandboxes it to
a directory, as well as providing versioned dependency management.

It's very simple and easy to use (there's only one new command), and adding it
to a project requires no changes to existing code. We've been using it where I
work and it's been very effective.

V1 is going to be released soon, check out the current version at
[https://github.com/mediocregopher/goat](https://github.com/mediocregopher/goat)

------
hannibalhorn
It's also work checking out glp: [https://github.com/cespare/go-
localpath](https://github.com/cespare/go-localpath) I've been using it quite
happily in several projects.

------
mmgutz
I recommend gvm which installs and manages go versions. If you want per
project workspace, create a pkgset for each. Linking the current directory to
the current workspace (pkgset) is something like this.

    
    
        # active workspace
        gvm pkgset use some-workspace
    
        # links current directory to some-workspace/src/github.com/you/foo
        gvm linkthis github.com/you/foo
    

This is more flexible as it allows a common work-in-progress project to be
linked to many workspaces.

------
zimbatm
Another option is to use direnv ([http://direnv.net](http://direnv.net)).

Just add this to your .envrc in your project's folder:

    
    
        PATH_add bin
        GOPATH="$PWD"
    

The environment is automatically loaded or unloaded whenever you enter or
leave the directory.

EDIT: Disclaimer, I'm the main author of direnv

------
myko
I've been using Gobrew:
[https://github.com/grobins2/gobrew](https://github.com/grobins2/gobrew)

It would be nice to standardize this a bit. I'm sure other Go devs I work with
use something different (I homerolled for awhile but I've been really pleased
with Gobrew).

------
33a
The fact that go even needs this is a sign that it's current package manager
is making all of the exact same mistakes as Python.

~~~
alcari
The fact that somebody's built it does not imply that it's generally needed,
or even useful.

------
jnazario
neat idea, and some neat feedback already from folks. while i'm just getting
started using go (like the features, can't quite say i'm enamored with the
syntax) i like the virtualenv paradigm and glad to see it ported to other
languages.

------
chimeracoder
Genuine curiosity: In practice, which Go packages that people use require
conflicting versions, necessitating a use for this tool?

In my experience, Go developers are generally good about building against
updated versions of packages. Combining that with the fact that binaries are
all compiled and statically linked (as opposed to dynamically linked or
interpreted), I can't remember ever running into the problem where packages X
and Y (that I both need) each depend on different versions of Z.

A big advantage of virtualenv in Python isn't relevant here: the ability to
specify a specific version of Python (not just 2 vs. 3, but minor versions as
well). With Go, you should _always_ be using the most recent version[0] of gc
or gccgo, as there is no reason not to.

[0] (If you are someone who actually needs two different versions of the Go gc
compiler installed on your system, you're probably on the core dev team, which
means you already know what you're doing and already avoid these tools for
other reasons.)

~~~
myko
In my case I've been using the excellent goandroid
([https://github.com/eliasnaur/goandroid](https://github.com/eliasnaur/goandroid))
to develop Android apps with Go and the NDK.

It's kind of a pain jumping around distributions manually, which is why I use
Gobrew to manage my goandroid Go environment and my normal Go environment.

