

GVM - the Go version manager - marketer
http://blog.moovweb.com/gvm-the-go-version-manager/

======
sirclueless
I 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.

~~~
FooBarWidget
And yet look at how many people use RVM. Just from user popularity alone it's
clear that system package managers, no matter how much they're praised by
sysadmin people, are not adequate. There's a clear need for package management
that's:

1\. cross-platform.

2\. allows users access to the latest version of the software _immediately_.

3\. allows installation of multiple versions. API/ABI stability is great but
_perfect_ backward compatibility is never possible. E.g. some apps actually
rely on bugs in the platform and if you fix them they break; yeah yeah I know
the software must be fixed but there may be a ton of reasons why that doesn't
happen or at least not happen immediately and there's a clear need among users
to be able to install multiple versions of a platform/library.

RPM/DEB theoretically support (2), but in practice distros never do that.
Third party packagers that immediately provide the latest versions are most
exception to the rule because they need to replicate their effort multiple
times over multiple platforms thanks to the lack of support for (1). RPM/DEB
don't even try to support (3).

~~~
koko775
Maven.

* Cross-platform.

* Easy access to remote packages as soon as they're posted.

* Versions _must_ specified, so builds are very repeatable. You bear the responsibility of updating your dependencies, but you don't get surprised if a version decides to break compatibility, either.

Also, very decentralized, and it's easy to create a directory locally to hold
the dependencies within a project (specify a file:// repository relative to
${project.dir}), or on a per-system-user level (mvn install), or on a per-
company/organizational unit basis (self-hosted repos are a cinch).

It's actually a fantastic package management system tailored to Java that
works extremely well. Its main problem is that it's also fantastically
verbose, and including more and more build plugins can grow exponentially more
arcane the greater the number of plugins involved. However, with Go's
standardized directory layout among other things (I admit, I haven't done much
research into trying Go out), something akin to Maven may actually be a good
fit.

~~~
lautis
As a user, i've been occasionally fristrated with the decentralized nature of
Maven. The isn't any single repository which would contain all packages
(especially rc/beta versions). And in my experience repos and which repos are
used to distributed a package tend to change fairly often. More often than
not, I have to hunt for new repos when building from scratch.

Maven is also very slow when your project has ~10 repos and you need to
download multiple dependencies. Having your own repo might be a necessity.

~~~
koko775
You can set up Artifactory on a nearby server you own and proxy all of your
package requests through it. Works quite well.

------
BarkMore
Because 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.

------
wglb
I 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'?

~~~
marketer
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.

~~~
masklinn
> Once Go 1 launches, subsequent releases should be compatible with the Go 1

Which does not mean that they _will_ be, despite Sun's effort to never
formally deprecate (let alone remove) anything and the glacial pace of the
language, there _have_ been backwards compatibility issues in the past:
reliance on implementation details or under-specified behavior which got
changed, reliance on bona-fide bugs which just happened to do what a developer
wanted in that case, etc...

~~~
wglb
I am getting that the GoFolk are building GOLANG with this problem firmly in
mind, and may just be expecting to avoid it.

~~~
masklinn
You can expect the unexpected not to happen all you want, reality won't care a
bit.

In fact, this makes me think of the Douglas Adams quote sitting right above my
main display:

"The major difference between a thing that might go wrong and a thing that
cannot possibly go wrong is that when a thing that cannot possibly go wrong
goes wrong it usually turns out to be impossible to get at or repair"

------
antrix
Sounds like`virtualenv` for Go. But shouldn't the need for this go away over
time as Go 1.0 use becomes widespread?

------
argaldo
ummm.. that name ... thought it was the Go! Virtual Machine

------
drivebyacct2
This 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!

