Flox - a new version manager

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.

Quick thoughts:

• the whole website is timing out for me so I had to use the Wayback Machine

• with regards to copyright, the phrase “public domain” has a specific meaning that doesn’t agree with its usage in lines like We now have a portable, deterministic environment, based on the largest repository of software in the public domain - for instance, even the MIT and Apache licenses are not “public domain”

thanks for this! A few answers:

• If asdf works for you, by all means use what works. I think what asdf offers is a basis, but you can take the idea of developer environments much further with flox: reproducible, shareable, isolated, etc.
• calling what asdf gives you an “environment” is a little bit of a stretch imo, it’s a runtime version manager. With nixpkgs, you can use any package it provides, not just node/elixir/ruby.
• you can’t share environments, or reproduce them. Nix gives you this: environments bit-for-bit reproducible and fully described by metadata you can store in github.
• you can specify the OTP version in these expressions, I should have added that.
  I’ve used asdf and I like it, it totally works. But I think if we start using reproducible environments based on nixpkgs, that’s a significant improvement, so that’s why we built flox.

OK, I missed the part about using NixOS and their containerized environments…

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

I have no experience with Flox, but I do intend to take a look at it.

I am personally looking into (and contributing) to devenv, which @ananthakumaran linked in the previous comment. I am really excited to see more movement and tools in this space, with or without Nix. Though, I believe that Nix makes it really easy to get started building something because of all of the packages (and different versions!) are already in the nixpkgs repo.

I really look forward to seeing all the tooling that comes out of this.

Agreed, the amount of experiments in the “Nix UX space” at the moment is incredible to see!

I’m a contributor to devbox (one of the most established nix tools with over 4k+ github stars) which @ananthakumaran also mentioned. Using nix, whether through devbox, devenv or flox solves a lot of problems around reproducibility and version pinning.

Devbox’s approach is to abstract the nix language away, for those who don’t want to learn it – if you prefer to learn the nix language, then devenv and flox can be great solutions as well.

I’m already using Nix flakes in my projects. I watched part of the NixCon talk about flox, so I kind of understand the vision, but I think the website is missing a page comparing flox with Nix flakes and why you would want to use one over the other.