A simple virtualenv for Go(github.com)

51 pointsby chuckha13 anni fa33 comments

https://github.com/ChuckHa/goenv

15 comments

jerf13 anni fa

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

chuckha13 anni fa

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

jerf13 anni fa

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.

olov13 anni fa

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.

jerf13 anni fa

Did not know that. Thanks!

arsenerei13 anni fa

How is yours safer?

jerf13 anni fa

Spaces in the path.

lotheac13 anni fa

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

chuckha13 anni fa

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.

laxk13 anni fa

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

chuckha13 anni fa

This is pretty cool, thanks for sharing.

jscheel13 anni fa

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?

chuckha13 anni fa

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.

BarkMore13 anni fa

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

[deleted]13 anni fa

eonil13 anni fa

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.

zackkitzmiller13 anni fa

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)

lstoll13 anni fa

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

chuckha13 anni fa

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

JulianMorrison13 anni fa

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.

2mur13 anni fa

This seems like a very reasonable approach. Thanks!

BarkMore13 anni fa

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

wilmoore13 anni fa

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.

mediocregopher13 anni fa

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

hannibalhorn13 anni fa

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

mmgutz13 anni fa

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.

zimbatm13 anni fa

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

myko13 anni fa

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

33a13 anni fa

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.

alcari13 anni fa

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

[deleted]13 anni fa

jnazario13 anni fa

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.

chimeracoder13 anni fa

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

myko13 anni fa

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.

BarkMore13 anni fa

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