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.
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.
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)
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.
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.
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).
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.)
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.
That's... simple, yes.
https://github.com/ChuckHa/goenv/blob/master/goenv