Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more
Manage multiple runtime versions with a single CLI tool, extendable via plugins
asdf-vm is a CLI tool that can manage multiple language runtime versions on a per-project basis. It is like gvm , nvm , rbenv & pyenv (and more) all in one! Simply install your language’s plugin!
Why use asdf-vm?
single CLI for multiple languages
consistent commands to manage all your languages
single global config keeping defaults in one place
single .tool-versions config file per project
support for existing config files .node-version , .nvmrc , .ruby-version for easy migration
automatically switches runtime versions as you traverse your directories
simple plugin system to add support for your language of choice
completion scripts managed by the plugin, not you!
Easy building and installing of Erlang/OTP instances
Kerl aims to be shell agnostic and its only dependencies, excluding what’s required to actually build Erlang/OTP, are curl and git .
All is done so that, once a specific release has been built, creating a new installation is as fast as possible.
OTP Support Policy
As of 2017 November 8, we are supporting OTP builds back to R15. Older builds may or may not work. We will advance release support as new releases of OTP become available. For example, when OTP 21 is released, we will support Erlang builds R16 and newer.
No. I use docker in production, so each app has it’s own image with it’s own version of whatever language it needs.
rvm for ruby, nvm for node, for java I’d usually just downloaded a specific version and then everything had to use that version. The other stuff I didn’t start using until after I was using asdf. The individual tools for each of the languages worked fine. It wasn’t until Elixir that I started using asdf, but it quickly replaced the others for me, since it meant I only needed to know one set of commands.
Currently using asdf since it’s simple straight-forward and gets the job done. If only this was around earlier as I would have preferred to use it over RVM/rbenv for Ruby.
Nix allows me to version way more things than just runtimes/compilers. Additionally this completely prevents me from Erlang/Elixir version mismatch. I use Nix also as my system package manager, so it is like Homebrew and ASDF in one package. Also the idea that I do not need to have packages available globally and instead have them per-environment is very useful.
You can version everything, DB, ElixirLS, Vim, OpenSSL, etc.
No, as Nix is whole functional programming language that is used to define working environment, so this is way harder to grasp and understand, but on the other hand it gives you enormous power as it can be used to:
define work environment
define CI environment
configure deployment builds
provide “simple” definition for others to run your application (for example if this is FLOSS or you need non-Elixir people to run it locally because they are for example mobile developers)
The last one is interesting, because imagine that you have your release defined in default.nix in your repo, so the user on the other end can do (IIRC, I am on my phone so it can differ a little):
let
my_app = fetchFromGit {
repo = "https://my-repo.url/repo.git"
};
in mkDerivation {
buildInputs = [my_app];
}
And they will have access your application via simple my_app start in their shell (if the derivation is properly written). So this provides way more possibilities than ASDF.
This thread has reminded me how useful #polls are on a forum. Not only can you quickly get a sense of that particular topic by looking at the poll results, but being able to discuss and seek clarification in the thread itself is incredibly useful.
Let’s try something new - whenever we post a poll on an important topic such as this one we’ll also pin it for a week. If that ends up being useful we’ll go through each of our polls on an annual basis and pin them for a week too, perhaps renewing them (with a new thread) every 3 to 5 years (depending whether there are new options available, etc).
I’m using it for all I can locally, but on production servers I stick with Erlang-solutions repo for Erlang/Elixir - benefits of switching version on production are doubtful, and besides that asdf only adds time to compile Erlang and hassle around users directories (afaik asdf can’t install packages globally)
that’s the case with properly pipelined deployments, I was talking about CI-less ones (I have both sorts of productions, and with CI-packaged deployments shipped to k8s of course I don’t use esl repos, but that was out of the question I guess)