21–30 of 36 posts
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
How is yours safer?
Earlier quoted context omitted.
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.
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.)
# active workspace
gvm pkgset use some-workspace
# links current directory to some-workspace/src/github.com/you/foo
gvm linkthis github.com/you/foo
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…
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 go even needs this is a sign that it's current package manager is making all of the exact same mistakes as Python.
It's too simple. PATH grows with each use of the tool.
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