I think a bunch of people here use asdf as a version manager, and others have moved to Nix. We built flox on Nix to make developer environments intuitive and super-powered, and we wrote a guide about migrating from asdf to flox here.
We’re working hard on making the Elixir experience first class, so feel free to sign up and give us feedback while we’re in beta.
Thanks!
14 Likes
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.
6 Likes
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”
4 Likes
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.
4 Likes
OK, I missed the part about using NixOS and their containerized environments…
1 Like
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 GitHub - 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 hello-phoenix/default.nix at main · flox-examples/hello-phoenix · GitHub and we have the ability to also create a companion dev env based on the same dependencies for building and releasing hello-phoenix/default.nix at main · flox-examples/hello-phoenix · GitHub
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.
6 Likes
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 — Determinate Systems
3: GitHub - jetpack-io/devbox: Instant, easy, and predictable development environments
6 Likes
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.
3 Likes
Agreed, the amount of experiments in the “Nix UX space” at the moment is incredible to see!
1 Like
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.
6 Likes
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.
2 Likes
flox is built on flakes, and interoperates with them fully. Will adjust the messaging to make that more clear 
Thanks
2 Likes
I wasn’t aware of devbox thanks @ananthakumaran @loreto I personally love working with GitHub - spf13/cobra: A Commander for modern Go CLI interactions this looks like a great project!
Also worth mentioning: flox is bringing flox publish and flox subscribe into the mix. With publish we introduce the concept of the catalog, which is an enhancement of the otherwise scattered data about flox and nix builds of your projects. We make it easier to integrate and use the caches of your choosing (s3, cachix, etc), and in the end because of publishing, subscribing and the catalog, we make it less likely that you’ll trigger builds on things your team has already identically built once. Also, our approach makes it easier to drop packages right into a project (still using a flake), but without needing to compose a lot of the bolierplate code in the flake to achieve using the package. This can help people even if one person on a team is a champion of nix or flox and knows nix, because it makes it much easier for the rest of the team to adopt nix by using flox.
I worked on an elixir team where we used nix shells for development environments prior to joining flox. Nix turned out to be a really good fit, and we extended it to Ruby on Rails projects as well. But the improvements in flox will make the experience even better, while still being compatible with nix just as @floxdev described above. But flox will also make it simpler to use the same approach in CI, and in deploying to production (even if you are not using nixos, or are using containers, etc)
2 Likes
This blog post [1] isn’t available anymore, and there is no cached version.
Is there an updated version of it?
Same thing with the Phoenix example app[2].
–
[1] https://flox.dev/blog/asdf-migration
[2] https://github.com/flox-examples/hello-phoenix
1 Like
@nivertech I am working up some phoenix examples using straight nix flakes for phoenix development (on linux for the moment)
I no longer work at flox, and now usually just use nix flakes directly, or https://devenv.sh/
1 Like
