Flox, a better alternative to Dev Containers | Hacker News Reader

Flox, a better alternative to Dev Containers

medium.com

45 pointspierrebeucher17 comments

In a similar vein but still containers and a bit more targeted: http://github.com/legobeat/l7-devenv

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 am curious how the company behind Flox intends to make money, I hope they intend to make money on consulting or operate non-profit sponsored by some institutions.

From what I gather it's exactly this in reverse: they already were a consulting company providing development environment to teams as part of their package, and Flox is an internal tool they open-sourced. (interpreted from what I read on their about page: https://flox.dev/about/)

Hey from Berlin! I'm Ron one of the founders at Flox and also board member of the NixOS Foundation. Just noticed folks are talking here and that's super exciting! We are all in the midst of the yearly NixCon so apologies if I'm slow to respond or my answers are a bit shorter. Definitely happy to dig deeper!

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.

Here's the project itself: https://github.com/flox/flox

Looks interesting, not that far from devenv I believe.

Though I do wonder, would we need those wrapper tools if vanilla nix was more intuitive to use...?

Short answer probably not. You can get most of the way there with nix + direnv. But nix is a complex beast even if you’re only using that little subset of it. I watched the development of this flox tool for a few months now, to me it seems closest to vanilla nix that still gives a nice UX. With devenv there seems to be more guardrails but also more proprietary flavor (the under the hood constructs are not entirely just raw nix)

I agree. Plain Nix is very complex but highly configurable and allow very complex use case, whereas Flox / devenv are much easier to setup but hide certain Nix features (which are probably not needed in most dev environments anyway, so it's totally worth it given the simpler interface)

Indeed. I find it hard to advocate for Nix at DayJob because it’s so fully loaded as a term. We are discussing the capabilities of Nix and are able to understand that the piece of Nix we are referring to is but one small piece of everything that is offered under the Nix umbrella. Nix is

- 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.

How does it compare to devenv? I have used that for a couple of months and now the gotchas makes me look for an alternative.

What are the gotchas?

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.

Wouldn't have said better, devenv and Flox are indeed similar and both uses Nix packages. We can say they are different frontends to the same set of packages, with slightly different features.

Both are great in my opinion.

So what are the gotchas?

I've just tried both `devenv` and `flox`, and the latter had two related niceties:

- 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.

it says in the article:

Easier to use and providing less friction than Dev Containers

https://devenv.sh/ and Dev Containers are not the same thing.

I sometimes wonder why Dev Containers is so slow. I've tried it on a project with a go, Python and nodejs toolchain, and pre-builds running on GitHub Actions usually take an hour and a half or more.

Reply on news.ycombinator.com