A simple virtualenv for Go | Hacker News Reader

A simple virtualenv for Go

github.com

51 pointschuckha33 comments

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

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

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.

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.

Did not know that. Thanks!

How is yours safer?

Spaces in the path.

This seems to copy a bad design decision from virtualenv. Please see https://gist.github.com/datagrok/2199506

This is pretty cool, thanks for sharing.

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

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.

You can try to use https://github.com/plar/goenv

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?

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.

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

I believe this is because they're in Google. For them, taking a VM instance would be more reasonable than multiplexing single machine into multiple virtualized environment.

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 (Pull requests also welcome)

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

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

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.

This seems like a very reasonable approach. Thanks!

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

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.

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

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

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.

Another option is to use direnv (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

I've been using 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).

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.

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

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.

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

Virutalenv also controls the application's runtime environment. This is not needed for Go.

In my case I've been using the excellent 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.

Reply on news.ycombinator.com