Top Related Projects
The SDKMAN! Command Line Interface
Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more
:blue_car: Like pyenv and rbenv, but for Go.
Quick Overview
GVM (Go Version Manager) is a tool for managing multiple versions of Go on a single system. It allows users to easily switch between different Go versions, install specific versions, and manage Go environments for different projects.
Pros
- Easy installation and setup process
- Supports multiple Go versions on the same machine
- Allows for project-specific Go version management
- Integrates well with shell environments
Cons
- Limited to Unix-like systems (Linux, macOS)
- May conflict with system-wide Go installations
- Requires manual updates for new Go versions
- Some users report occasional stability issues
Getting Started
To install GVM, run the following commands:
bash < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)
source ~/.gvm/scripts/gvm
After installation, you can use GVM to manage Go versions:
# List available Go versions
gvm list
# Install a specific Go version
gvm install go1.16
# Use a specific Go version
gvm use go1.16
# Set a default Go version
gvm use go1.16 --default
To use a specific Go version for a project, create a .gvmrc
file in the project root:
echo "go1.16" > .gvmrc
This will automatically switch to Go 1.16 when you enter the project directory.
Competitor Comparisons
The SDKMAN! Command Line Interface
Pros of SDKMAN
- Supports a wider range of programming languages and tools
- More active development and community support
- Easier installation process with a single command
Cons of SDKMAN
- Slower performance for some operations compared to GVM
- Limited support for Windows operating systems
- More complex codebase, potentially making it harder to contribute
Code Comparison
GVM:
gvm install go1.16
gvm use go1.16
gvm list
SDKMAN:
sdk install java 11.0.12-open
sdk use java 11.0.12-open
sdk list java
Both tools use similar command structures for installing, using, and listing versions. However, GVM focuses primarily on Go versions, while SDKMAN supports multiple SDKs and tools.
SDKMAN offers a more comprehensive solution for managing various development kits, making it suitable for developers working with multiple languages. GVM, on the other hand, provides a more streamlined experience for Go developers, with potentially faster performance for Go-specific tasks.
The choice between the two depends on the user's specific needs and the programming languages they work with. SDKMAN is better for those requiring support for multiple SDKs, while GVM is ideal for Go-centric development environments.
Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more
Pros of asdf
- Supports multiple programming languages and tools, not just Go
- Plugin-based architecture allows for easy extension
- Provides a unified interface for managing different runtime versions
Cons of asdf
- Requires installation of plugins for each language/tool
- May have a steeper learning curve due to its multi-language support
- Potentially slower performance compared to language-specific version managers
Code Comparison
asdf:
asdf plugin add golang
asdf install golang 1.16.0
asdf global golang 1.16.0
gvm:
gvm install go1.16
gvm use go1.16
Key Differences
- gvm is specifically designed for Go, while asdf is a general-purpose version manager
- asdf requires plugin installation for each language, gvm is ready to use for Go out of the box
- gvm provides Go-specific features like cross-compilation, while asdf offers a consistent experience across multiple languages
Use Cases
- Choose gvm if you primarily work with Go and want a dedicated, optimized solution
- Opt for asdf if you frequently switch between multiple programming languages and prefer a unified version management approach
Community and Maintenance
- gvm has a smaller, Go-focused community
- asdf has a larger, more diverse community due to its multi-language support
- Both projects are actively maintained, with regular updates and contributions
:blue_car: Like pyenv and rbenv, but for Go.
Pros of goenv
- Simpler installation process, doesn't require shell scripts
- Better support for Windows environments
- More active development and maintenance
Cons of goenv
- Fewer features compared to gvm (e.g., no package set management)
- Less flexible in terms of customization options
- Smaller community and ecosystem
Code Comparison
gvm:
gvm install go1.16
gvm use go1.16
gvm pkgset create myproject
gvm pkgset use myproject
goenv:
goenv install 1.16.0
goenv global 1.16.0
# No direct equivalent for package set management
Both gvm and goenv are Go version management tools, but they differ in their approach and feature set. gvm offers more advanced features like package set management, while goenv focuses on simplicity and cross-platform compatibility.
gvm provides a more comprehensive solution for managing Go environments, including the ability to create and switch between different package sets. This can be beneficial for developers working on multiple projects with different dependencies.
goenv, on the other hand, offers a more straightforward approach to Go version management. It's easier to set up and use, especially for beginners or those who don't need the advanced features of gvm. goenv also has better support for Windows, making it a more versatile choice for cross-platform development teams.
Ultimately, the choice between gvm and goenv depends on your specific needs and development environment. If you require advanced features and don't mind a more complex setup, gvm might be the better choice. For simpler version management needs or cross-platform compatibility, goenv could be the more suitable option.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
gvm
By Josh Bussdieker (jbuss, jaja, jbussdieker) while working at Moovweb
Currently lovingly maintained by Benjamin Knigge
Pull requests and other any other contributions would be very much appreciated.
GVM provides an interface to manage Go versions.
Features
- Install/Uninstall Go versions with
gvm install [tag]
where tag is "60.3", "go1", "weekly.2011-11-08", or "tip" - List added/removed files in GOROOT with
gvm diff
- Manage GOPATHs with
gvm pkgset [create/use/delete] [name]
. Use--local
asname
to manage repository under local path (/path/to/repo/.gvm_local
). - List latest release tags with
gvm listall
. Use--all
to list weekly as well. - Cache a clean copy of the latest Go source for multiple version installs.
- Link project directories into GOPATH
Background
When we started developing in Go mismatched dependencies and API changes plagued our build process and made it extremely difficult to merge with other peoples changes.
After nuking my entire GOROOT several times and rebuilding I decided to come up with a tool to oversee the process. It eventually evolved into what gvm is today.
Installing
To install:
-
Install Bison:
sudo apt-get install bison
-
Install gvm:
bash < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)
Or if you are using zsh just change bash
with zsh
Installing Go
gvm install go1.4
gvm use go1.4 [--default]
Once this is done Go will be in the path and ready to use. $GOROOT and $GOPATH are set automatically.
Additional options can be specified when installing Go:
Usage: gvm install [version] [options]
-s, --source=SOURCE Install Go from specified source.
-n, --name=NAME Override the default name for this version.
-pb, --with-protobuf Install Go protocol buffers.
-b, --with-build-tools Install package build tools.
-B, --binary Only install from binary.
--prefer-binary Attempt a binary install, falling back to source.
-h, --help Display this message.
A Note on Compiling Go 1.5+
Go 1.5+ removed the C compilers from the toolchain and replaced them with one written in Go. Obviously, this creates a bootstrapping problem if you don't already have a working Go install. In order to compile Go 1.5+, make sure Go 1.4 is installed first. If Go 1.4 won't install try a later version (e.g. go1.5), just make sure you have the -B
option after the version number.
gvm install go1.4 -B
gvm use go1.4
export GOROOT_BOOTSTRAP=$GOROOT
gvm install go1.7
A Note on ARMv6 and ARMv7 architectures (32 bit)
Binary versions for ARMv6 architecture are available starting from Go 1.6. So, it is necessary to bootstrap with an existing binary version, then it will be possible compiling other versions. For instance, to bootstrap a setup, version 1.21.0
may be used:
gvm install go1.21.0 -B
gvm use go1.21.0
And then, compile any other version:
gvm install go1.20.7
To install Go 1.20+
Go 1.20+ requires go1.17.3+. Use the below:
gvm install go1.4 -B
gvm use go1.4
export GOROOT_BOOTSTRAP=$GOROOT
gvm install go1.17.13
gvm use go1.17.13
export GOROOT_BOOTSTRAP=$GOROOT
gvm install go1.20
gvm use go1.20
List Go Versions
To list all installed Go versions (The current version is prefixed with "=>"):
gvm list
To list all Go versions available for download:
gvm listall
Uninstalling
To completely remove gvm and all installed Go versions and packages:
gvm implode
If that doesn't work see the troubleshooting steps at the bottom of this page.
Mac OS X Requirements
- Install Mercurial from https://www.mercurial-scm.org/downloads
- Install Xcode Command Line Tools from the App Store.
xcode-select --install
brew update
brew install mercurial
Linux Requirements
Debian/Ubuntu
sudo apt-get install curl git mercurial make binutils bison gcc build-essential
Redhat/Centos
sudo yum install curl
sudo yum install git
sudo yum install make
sudo yum install bison
sudo yum install gcc
sudo yum install glibc-devel
- Install Mercurial from http://pkgs.repoforge.org/mercurial/
FreeBSD Requirements
sudo pkg_add -r bash
sudo pkg_add -r git
sudo pkg_add -r mercurial
Vendoring Native Code and Dependencies
GVM supports vendoring package set-specific native code and related dependencies, which is useful if you need to qualify a new configuration or version of one of these dependencies against a last-known-good version in an isolated manner. Such behavior is critical to maintaining good release engineering and production environment hygiene.
As a convenience matter, GVM will furnish the following environment variables to aid in this manner if you want to decouple your work from what the operating system provides:
-
${GVM_OVERLAY_PREFIX}
functions in a manner akin to a root directory hierarchy suitable for auto{conf,make,tools} where it could be passed in to./configure --prefix=${GVM_OVERLAY_PREFIX}
and not conflict with any existing operating system artifacts and hermetically be used by your workspace. This is suitable to use withC{PP,XX}FLAGS and LDFLAGS
, but you will have to manage these yourself, since each tool that uses them is different. -
${PATH}
includes${GVM_OVERLAY_PREFIX}/bin
so that any tools you manually install will reside there, available for you. -
${LD_LIBRARY_PATH}
includes${GVM_OVERLAY_PREFIX}/lib
so that any runtime library searching can be fulfilled there on FreeBSD and Linux. -
${DYLD_LIBRARY_PATH}
includes${GVM_OVERLAY_PREFIX}/lib
so that any runtime library searching can be fulfilled there on Mac OS X. -
${PKG_CONFIG_PATH}
includes${GVM_OVERLAY_PREFIX}/lib/pkgconfig
so thatpkg-config
can automatically resolve any vendored dependencies.
Recipe for success:
gvm use go1.1
gvm pkgset use current-known-good
# Let's assume that this includes some C headers and native libraries, which
# Go's CGO facility wraps for us. Let's assume that these native
# dependencies are at version V.
gvm pkgset create trial-next-version
# Let's assume that V+1 has come along and you want to safely trial it in
# your workspace.
gvm pkgset use trial-next-version
# Do your work here replicating current-known-good from above, but install
# V+1 into ${GVM_OVERLAY_PREFIX}.
See examples/native for a working example.
Troubleshooting
Sometimes especially during upgrades the state of gvm's files can get mixed up. This is mostly true for upgrade from older version than 0.0.8. Changes are slowing down and a LTR is imminent. But for now rm -rf ~/.gvm
will always remove gvm. Stay tuned!
Top Related Projects
The SDKMAN! Command Line Interface
Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more
:blue_car: Like pyenv and rbenv, but for Go.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot