The question is why, I mean asdf is a little bit of a hassle to set the first time, since all the versions of OTP you install are compiled on your device, however once you install all the dependencies it works like a charm.

The environment setup is a thing that I love about asdf, simple and declarative: use global versions for all projects and local for the projects with .tools-versions defined. You will never use a different version locally to develop on a released product, even if you have to you can just modify/delete .tools-versions locally.

The last thing that I don’t see is the possibility to define the OTP version, this is one of the most important features of the version tool, moreover the elixir should be compiled with that specific OTP version to ensure that all the features work correctly.

A flox engineer here: I want to add that the blog post does a great job at highlighting some of the best features of flox. But it doesn’t cover as much about the reality that flox is composible and declarative for a project with not just elixir, but also erlang (and you can choose your own OTP version, or even set up a compile from source yourself) and also manage a specific graph of dependencies for all of the other dependencies and services you will use along with your elixir project. An example is the hello-phoenix working example we put together here https://github.com/flox-examples/hello-phoenix

You can see in that example that we have the ability to build and release a pure and deterministic build of the phoenix app https://github.com/flox-examples/hello-phoenix/blob/main/pkgs/hello-phoenix/default.nix and we have the ability to also create a companion dev env based on the same dependencies for building and releasing https://github.com/flox-examples/hello-phoenix/blob/main/pkgs/phx-shell/default.nix

A team can add these to their project repos, and use these through the whole development lifecycle (dev, CI and replease to production). For linux machines, these configs can be loaded into docker images and deployed that way directly from the package. These packages (the release and the dev env) can also be flox published and then subscribed to. Then, they can be used immediately in the way that is described in the blog post above. This approach also prevents the rebuilding of deps unless a dependency has changed. Overall, this has created a comprehensive way to build, publish, install and share across the whole lifecycle.

At my first job in a ruby shop, I had to install ruby gems by hand. God knows which version would get installed. Luckily, Bundler became the standard and Gemfile.lock made it possible to create reproducible environment. Soon nearly all the languages started to have lock file variants. But for some reason, that stopped at language library level. Any dependency on OS package level like imagemagick, mysql-client etc are still managed by hand in most cases. Nix is trying to tackle the problem, I have been trying to convert people to use nix shell, I add shell.nix in most projects nowadays. Nix Flakes seem to be the ideal as it locks the version as well, but it has been in beta for a long time and I am yet to find good documentation. Meanwhile, everybody else seems to see the potential and starting to build on top of nix. I am hoping somebody will solve this problem, we would waste less time debugging build failures and claiming it works on my machine.

1: https://devenv.sh/
2: An invitation to Rust maintainers
3: GitHub - jetify-com/devbox: Instant, easy, and predictable development environments · GitHub