A simple virtualenv for Go

by chuckha • 13 years ago

51 33 13 years ago

jerf4• 13 years ago

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

chuckha5• 13 years ago

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

jerf4• 13 years ago

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.

arsenerei• 13 years ago

How is yours safer?

jerf4• 13 years ago

Spaces in the path.

lotheac• 13 years ago

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

chuckha5• 13 years ago

This is pretty cool, thanks for sharing.

chuckha5• 13 years ago

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.

laxk• 13 years ago

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

zackkitzmiller• 13 years ago

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)

BarkMore3• 13 years ago

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

wilmoore• 13 years ago

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.

jnazario• 13 years ago

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.

hannibalhorn• 13 years ago

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

myko2• 13 years ago

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

lstoll• 13 years ago

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

chuckha5• 13 years ago

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

JulianMorrison• 13 years ago

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• 13 years ago

This seems like a very reasonable approach. Thanks!

jscheel• 13 years ago

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?

chuckha5• 13 years ago

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.

BarkMore3• 13 years ago

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

eonil• 13 years ago

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.

chimeracoder• 13 years ago

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

BarkMore3• 13 years ago

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

myko2• 13 years ago

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.

mmgutz• 13 years ago

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.

33a• 13 years ago

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• 13 years ago

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

mediocregopher• 13 years ago

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

zimbatm• 13 years ago

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

A simple virtualenv for Go

Related Stories