GVM - the Go version manager
blog.moovweb.com
GVM - the Go version manager
1–10 of 19 posts
Re: GVM - the Go version manager
#2This is slick. I will note though, if you're just getting started with Go or if you only have small projects, this is overkill. `go fix` and just starting out with current weeklies (RCs for Go1) is sufficient. For projects of any substantial size though, this looks like a nice handy tool!
Re: GVM - the Go version manager
#3I kind of think of RVM as a necessary bug due to the unmanaged span of Ruby versions.
I am not clear why this is really necessary for GO. Why not just use 'go fix'?
Re: GVM - the Go version manager
#4I kind of think of RVM as a necessary bug due to the unmanaged span of Ruby versions. I am not clear why this is really necessary for GO. Why not just use 'go fix'?
For simple projects or toy apps, gofix is just fine. However, some companies are running complex production systems written in GO 0, and the code may have a lot of dependencies and custom build scripts. In this case it's useful to have an easy way to install and pin Go versions.
Once Go 1 launches, subsequent releases should be compatible with the Go 1, which reduces the need for something like GVM.
Re: GVM - the Go version manager
#5I kind of think of RVM as a necessary bug due to the unmanaged span of Ruby versions. I am not clear why this is really necessary for GO. Why not just use 'go fix'?
I wouldn't consider it "necessary" however even the casual Go user can benefit from the automatic environment setup GVM provides. Go is quickly becoming my language of choice and GVM has spared me the hassle of GOROOT and GOPATH setup. Plus I keep anxiously checking `gvm listall` for the Go1 tag
Re: GVM - the Go version manager
#6Sounds like`virtualenv` for Go. But shouldn't the need for this go away over time as Go 1.0 use becomes widespread?
Re: GVM - the Go version manager
#7Because Go builds statically linked executable files, the GVM tool only applies to development environments.
As far as the development environment is concerned, I find it easy to manage multiple versions of Go by setting $PATH and $GOPATH as needed. I only work with a couple of versions of Go at a time and I don't share packages between versions of Go, so my situation might be simpler than what they have at moovweb.
I expect that I will mostly use a single version of Go after Go 1 is released next week.
Re: GVM - the Go version manager
#8I actually hope this doesn't take off (or at least, if it does, that it keeps its scope in check). RVM is invasive and moderately broken because of that.
And besides, in a very short time, Go is going to commit to API stability with Go 1. And given that, and static typing (even at runtime), and Go's beautiful module system, and the fact that static linking is the norm, all means that worrying about which Go version you are running on is a silly concern.
This tool purports to solve dependency hell, but dependency hell, especially in a language with no stable ABI where everything is compiled from source, is entirely about package management. Go's standard library used to be in flux, which made pinning a version an important piece of ensuring source compatibility with packages. That's about to go away, and I hope GVM-like tools will follow.
Re: GVM - the Go version manager
#9I kind of think of RVM as a necessary bug due to the unmanaged span of Ruby versions. I am not clear why this is really necessary for GO. Why not just use 'go fix'?
Yeah, I think RVM also kind of proved that build tools that inject themselves via .bashrc are more trouble than they're worth. It was somewhat forgivable with Ruby because they had decades of legacy tools to deal with; one would hope Go would be able to find a better solution.
Re: GVM - the Go version manager
#10ummm.. that name ... thought it was the Go! Virtual Machine