Which Elixir version manager are you using? (Poll)

  • asdf
  • exenv
  • kerl
  • kiex
  • none
  • other
0 voters

asdf

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!

exenv

Groom your app’s Elixir environment with exenv

Based totally on the GREAT rbenv

rbenv’s documentation largely applies here as well

kiex

Kiex allows you to easily build and switch between different Elixir versions.

It supports setting the default (global) Elixir version as well as per shell/project versions.

Everything is self-contained under ~/.kiex.

Usage is based lightly on RVM, kerl, and rbenv.

NOTE: Some Erlang source builds are broken. See below

kerl

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.

1 Like

For anyone using ASDF - are you using it with other languages as well? How are you getting on?

@akitaonrails - are you still happy using it for Ruby as well?

2 Likes

I use asdf for everything: elixir, erlang, javascript, yarn, ruby, java, kotlin, rust, terraform

17 Likes

Nix is life, Nix is love

I have previously used ASDF and I was using it for a lot of stuff - Ruby, Terraform, Consul, Packer, Rust (partially), Node, etc.

6 Likes

Nice! Do you use it in production as well Allen?

What did you use previously and how do they compare?

What made you change to Nix Łukasz?

Can you use Nix fo Ruby as well? Is Nix as easy to use as ASDF?

Yes, I have been using it for years, not only for Ruby but for every other language I have installed.

2 Likes

I use asdf for everything, for prod I don’t have erlang or elixir installed :), it’s all bundled with my app thanks to releases!

3 Likes

I have a few Ruby apps hence wondered what ASDF is like in production :smiley:

I currently use Chruby for them which I really like. This is a really good blog post about Chruby and details some of its benefits.

1 Like

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.

3 Likes

It’s worth mentioning, in some cases, asdf is wrapping language specific version managers. Like the erlang plugin uses kerl and ruby uses ruby-build.

6 Likes

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.

3 Likes

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.

7 Likes

The GitHub Action for Gleam uses asdf to set up the Gleam compiler for use in CI pipelines :slight_smile:

4 Likes

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).

8 Likes

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) :slight_smile:

3 Likes

I generally prefer running whichever version I need in a container.

1 Like

Why not distribute ERTS with the release? This is safer and default solution in mix release and Distillery.

3 Likes

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) :slight_smile:

2 Likes

Would you make a blog post describing how are you utilising it exactly?

2 Likes