Flox, a better alternative to Dev Containers(medium.com) |
Flox, a better alternative to Dev Containers(medium.com) |
I daily-drove NixOS for a few years and philosophically very much vibe with the foundational ideas. Gave up on it because it was too much involved in getting productive with writing and maintaining nix configurations.
I saw your question and actually wanted to share the response I shared a few months ago, happy to unpack or talk about any of it as well.
This is from our original 1.0 announcement here (https://news.ycombinator.com/item?id=39692801) -> bringing forward what you saw today for free and open source, was a major part of why I started Flox, with much more to come into it. What we released today will be free forever (both the open source client and the FloxHub services for sharing environments). We plan on expanding the offering to include a more robust private software catalogs that layers on top of the OOTB Flox Catalog that ships with Flox. If you are interested in publishing your output or need revised versions of open source packages in Flox then it'll be very easy to have your own catalog to compliment the always-free Flox Catalog that Flox ships with today. Beyond that, we are focused on a number of services that help bring Nix's build to the enterprise. Over time we intend to sell a solution to enterprises - through subscriptions and services - so they can more effectively manage expansive and fragmented software supply chains. As part of developing custom tooling for enterprises, we think it's reasonable for them to participate in funding for that work.
Though I do wonder, would we need those wrapper tools if vanilla nix was more intuitive to use...?
I’ve used Nix for 6 months, and it beats Devcontainers at a higher cost, but with less IDE lock-in.
Devenv, as far as I understand, is a convenience layer on top of Nix. Just as Flox is.
Both are great in my opinion.
Easier to use and providing less friction than Dev Containers
- a package manager for system packages
- a methodology to declaratively manage your local environment
- a methodology to declaratively manage your entire machine
- a deterministic build tool
- an entire operating system
We know we are really only talking about the first two in this conversation but for some random engineer in your org who has no idea what Nix is it’s extremely easy to get caught in a rabbit hole of the other bullet points even though they are not relevant at all to this conversation. So I think it’s generally pretty risky to even mention Nix as an option because it has so many nerd traps that ultimately end up as distractions to do what you are trying to do. So I absolutely see the value in toolchains like this that try to hide that away but still reap the benefits of the ecosystem.
- Direnv wants to put its config inside the root of a git repo, which makes it hard to ignore. Flox's config is all in a `.flox` directory, so I could `echo * >> .flox/.gitignore` in any repo without changing the repo's gitignore.
- There seems to be no way to run `direnv` on an environment that's not the current working dir, see https://github.com/cachix/devenv/issues/67.
OTOH, `flox` was a bit harder to install in an existing nix setup and requires trusting their cache, at least if I wanted to do a cached install. You can follow the instructions in https://flox.dev/docs/install-flox/#__tabbed_1_6, or you could add yourself to Nix's "trusted users" (which makes sense only if you're the only user on the computer using Nix). See also https://github.com/flox/flox/issues/1179.