I use ASDF for everything, but I’m curious which version managers everyone else are using.
3 Likes
Before discovering asdf I was between my distro repo version, or straight up containers to manage different versions.
But usually I didn’t need to worry so much about different versions of Erlang as I did with Python and Node. It was more stable and the few deprecating features weren’t such a liability with each release.
Elixir kinda pushed me to care about Erlang and Elixir version management.
2 Likes
kerl here (is used underneath asdf too). asdf has too many moving parts for me and therefore broke a few times so I’m back to the basics
7 Likes
For my specific case is necessary because I also have python and node projects requiring different runtimes, asdf just handles all that without much headaches.
Each version management/building tool will have its own quirks, each person will have its own tolerance levels to these quirks.
2 Likes
Nix for everything. My OS and per project env (in tandem with Direnv).
7 Likes
+1 for kerl.
2 Likes
This is the way
3 Likes
Do you publish your config? I’ve wanted to move from my homemade bootstrap script (that’s what https://yadm.io uses) to Nix but I just don’t grok it.
2 Likes
Started coding on Alpine Linux for most of my erlang projects and i dont worry about erlang versions.
Usually the system package management tool is good enough for erlang.
2 Likes
I currently have mix of “classic dot files” and Nix - ~hauleth/dotfiles: flake.nix - sourcehut git
5 Likes
I used exclusively asdf for almost all language version managers that it supports and I need to use it, including Erlang, so far can’t complain about it.
If you are interested in using GitHub Actions in combination with .tool-versions files for version management, I recommend you to take a look at github-actions-workflows/elixir/setup at master · straw-hat-team/github-actions-workflows · GitHub I am a maintainer of it. Here is about getting a version out of the asdf .tool-versions file github-actions-workflows/asdf/get-version at master · straw-hat-team/github-actions-workflows · GitHub
3 Likes
I use asdf for everything.
2 Likes
A useful tip for all asdf users.
If you are managing Python and/or Ruby versions with asdf, make sure to set the global Python and Ruby versions to system, and then set local versions inside the directories you put Python and Ruby projects in. This way, the versions of these languages installed through asdf won’t conflict with versions installed by the OS.
My global .tool_versions file looks like:
...
kotlin 1.6.10
python system
ruby system
rust 1.58.1
...
3 Likes
I use https://github.com/tsloughter/erlup/ that I started partly just to write a project in Rust to learn.
Hope to soon make it easy to install, like rustup, and support installing Erlang versions from binary tarball.
5 Likes
I use asdf but with my Erlang plugin for Ubuntu which doesn’t compile from source (uses Erlang binary builds from Hex)
2 Likes
Thought about importing that functionality into the main erlang plugin for asdf?
2 Likes
I tend to gravitate towards 
WASD when I should be more productive 
2 Likes
I shared the idea in their repo, it would be great to have it there! I’m not a Linux packaging expert myself, but I think to move it there someone would need to:
- Confirm those builds provide all functionality that regular asdf Erlang builds provide
- Detect that the system is compatible with the prebuilt versions (x86-64 architecture, distribution, if it’s Ubuntu based then pick latest LTS version for user’s version, anything else?)
- Ensure that a prebuilt version is available for the version number the user requested, and their system combination
- Document the plugin behavior (when would prebuilt versions be used instead of building from source with
kerl, how it relates to other configuration of the plugin), maybe add configuration
There also was a question of whether the OTP team will provide prebuilt Erlang for Linux (I think the answer is still “maybe”)
3 Likes