Show HN: Flox 1.0 – Open-source dev env as code with Nix

Or https://devenv.sh

Flox employee here! To start off by addressing how this relates to nix tools:

- Our goal is to be more user friendly. You don't have to learn the Nix expression language or understand nix internals to be successful.

- We've been able to add some opinionation and polish. Some of that is subjective, but some examples are:

  - We have a hybrid imperative/declarative interface. You can `flox install && flox list`, and those changes are reflected in TOML. Whereas with `nix develop` you have to edit a Nix expression

  - `nix develop` drops you into a bash shell, whereas `flox activate` can drop you into a bash or zsh shell (and we plan to add support for fish)

Put another way, I would think that individual engineers would be better off learning the underlying tech and the tools provided that go with them. I think it's very possible that Flox (or devenv or...) reaches EOL, or ceases to track nixpkgs appropriately, or any of the other ways that software rots. Where nix develop is going to last as long as Nix Flakes do, and there's incentive to provide a migration path to whatever's next.

Even more important: every abstraction is going to leak. Maybe the Flox CLI "looks" cleaner or whatever, but in the end you'll still need to learn Nix to use it effectively. Why learn twice as much stuff as you need?

"Flox began its life during the deployment of Nix at the D. E. Shaw group, where it quickly proved invaluable by making Nix easier for newcomers".

Is that the line you are referring to? Sounds like the opposite of what you suggests it says.

I think once somebody solves the hellish configuration with another language that people can actually understand NixOs will take off. I mean, I hate js as much as everybody else, but I’d rather use that to configure nix than whatever that thing is that they use now.

I love nix and have contributed quite a few packages to the nix repository, and I will vouch that it’s anything but easy. I have a background in Haskell which makes it more familiar, but even the syntax is counterintuitive to newcomers.

Exact same experience here. Been fiddling with nixos for quite a while, but never got comfortable with .nix or flakes. The base concepts keep escaping my mind, I have to revisit every time I have to configure something new and I just got tired. Issues are difficult to debug and you have to go through very specific commands and a hellish filesystem to understand what's going wrong. I love the concept, but I feel like it just gets too much in my way.

I used the repl from day 1 and it was so intuitive. No other alternative has a repl (besides guix I guess)

Hard agree. I see the advantages but the initial learning curve is incredibly steep. Funny how this mimics my experience with Rust.

Agreed on the experience, hard to onboard. I looked at devenv.sh as easier way to get going. Implemented all with Nix, less lock-in. Just found std [0] and that looks quite promising too.

[0] https://std.divnix.com/

I read that as Flox makes nix easier for newcomers, not that nix is easy for newcomers.

Devbox can also run services too. Both products use an awesome process runner called process-compose (https://github.com/f1bonacc1/process-compose/) which is worth checking out (it's even built with nix!)

+1 to devenv. I used to use Nix natively, then switched to devbox and then devenv. devenv is the most intuitive to use. I just wish that I could just run a command using devenv (similar to nix run) instead of having to declare it in the devenv.nix first.

Not nix based, but I really like https://github.com/jdx/mise too to manage dev tools.

It’s a modern version of https://github.com/asdf-vm/asdf written in Rust.

I have used devbox and have been keeping an eye on other options. Haven't tried devenv yet. Any thoughts on devenv vs flox given what we're seeing here?

Nix allows you to have a single lock file for all your dependencies. This is very useful for development environments. When you share a lock file via Git, then you know your colleagues will be running the same versions.

Great list.

Using devbox myself and very happy with it.

Would be great to hear what separates flox from the rest.

but worried that the development is not moving forward

There is an open v1.0 PR: https://github.com/cachix/devenv/pull/1005

As opposed to Docker, or Bazel?

Conversely I have never had this problem with Nix. It tells you plainly how to clean up garbage. It's easy to interrogate to find out what's hanging around, and why. The reason it's not on by default is that, like any garbage collector, it can be disruptive -- there is no "one size fits all" policy.

Ultimately if you have too many gc roots you have to make some decisions.

We have the same problem with bazel at work, after a few months your machine is running out of disk space

Just set nix garbage collect to run every thirty minutes.

Supporting rollback and history means disks can fill up. With Nix, this is usually due to a bunch of GC roots pointing to profiles and packages that then cannot be cleaned up. Our environments are not just symlinks, but have a declarative format (under the hood, flakes) so one can remove them, but also reproduce them as needed. So GC'ing them is less destructive than with using `nix-env`/`nix profile`. This allows us to be more aggressive in cleaning up old generations.

So the strategy is to ensure there is always a declarative+reproducible way to recover the things you clean up, then we can apply various heuristics to avoid disks from filling up; free space, age, least-recently-used, least-frequently-used - are all being considered.

Nix supports garbage collection.

Also there are literally thousands of insanely complex things happening behind the scenes every time you use your computer. Not sure why Nix is considered special when abstracting over it.

I just want clean, repeatable environments for different projects. I’ve tried getting into Nix a few times but I always get overwhelmed by all the different things it is/does. This looks 100x simpler to me.

I understand that Nix solves many problems and indeed bet on its ability to do so. It is why I've put so much effort into Nix itself.

However, Nix poses a relatively steep learning curve being built up from first principles making it very general. Flox aims at simplifying this by narrowing the problem field and providing specialized abstractions and interfaces for those who want to benefit from nix' capabilities without needing to becoming a nix expert at day 0.

(flox employee)

Selling coworkers on flox or devenv is way easier than Nix.

You don't need to choose :). You can use Devcontainers with most of the Nix tools, including Devbox. See https://containers.dev/supporting

They're nice, but they lock you into vscode

Appreciate the call out. Regarding pricing, 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.

Crunchbase links to news articles that make it seem like you've raised $24MM.

Oh wow. I really don't see a way to a $2.4B exit here. Good luck!

I believe so, it seems like almost all (or all?) solutions listed here: https://news.ycombinator.com/item?id=39696038 use flakes underneath.

I think the flakes problem come from two things:

- flakes are labelled experimental for years now (I think it might be almost 5 years now) which creates confusion with new users, but they are universally used nearly everywhere now - there seems to be some bad blood[1] between https://determinate.systems/ company and the long time Nix users and developers who are accusing them that they are using Nix for their benefit with not contributing back. From my understanding Determinate Systems introduced flakes and probably this why there's some resistance to it by some.

But to answer your question, pretty much everyone adopted flakes and guides that don't use them are most likely old.

[1] https://discourse.nixos.org/t/introducing-flakehub/32044

I don’t know anyone who is recommending against flakes these days. The “experimental” label is more about the API stability than completeness, bugginess, or anything else.

There are certain scenarios where the performance can be problematic, but there are workarounds and permanent solutions are being worked on. Nevertheless, using flakes extensively at home and work.

See: A plan to stabilize the new CLI and Flakes incrementally https://github.com/NixOS/rfcs/pull/136

On non-Linux it should be faster/less overhead; on all platforms I suppose it's just arguably easier/quicker to make changes & 'rebuild', and then the result is that that just is your environment, it's not a container inside it that you have to exec into or run commands through or make your IDE use or whatever.

But mostly it's just two different approaches and people will be happy to argue about why there's is better, or that they don't use either (just the system environment (on a non-NixOS system..) as it were).

It's not necessarily that one is better than another; it can be complementary. I tend to think that Nix makes many of the reasons to use a container superfluous, but there still remain other reasons to use containers.

For example, a talk about using both Docker and Nix (yep, that's me ;) ): https://www.youtube.com/watch?v=l17oRkhgqHE

I have to use both at the same time.

I have a Docker with an old version of centos which for some reason is the one provided to us.

I then create an "overlay" over it using nix, so I can actually use software with newer glibc etc... easily.

Regardless of that, nix is way better than docker, in the sense that docker doesn't ensure reproducibility, you can build a Dockerfile in two different days, and get different versions of packages installed, this is simply not possible with nix, you have complete control over your tools.

And if you decide to port your application to a "nix package", you have complete control over all the dependencies of you application, a reproducible way to build it, and an easy way to deploy it.

Happy to take this one, as I am one of the cofounder of Daytona.

Daytona solves all the automation and provisioning of the dev environment, actually wrote an article here laying out exactly what we do: https://www.daytona.io/dotfiles/diy-guide-to-transform-any-m...

Daytona currently supports only the dev container (https://containers.dev/) "dev env infrastructure as code" standard, but are looking to support others such as devfile, nix and flox.

Hope this helps

It can, but I wouldn't recommend it unless you have native dependencies that are just a pain to install. You'll loose Windows compatibility, may have to package some Python packages yourself, have a learning curve for everyone in the Python ecosystem and gain... what exactly?

The python ecosystem will require specific support, so at the moment we recommend using `flox` to get all of the other things that might not be managed by an existing Python package manager, and/or to install that package manager itself.

Being a general solution, `flox` cannot directly provide the same level of integration as a python-specific tool, but we CAN make it easier to use those other tools, and bring in others.

Using Nix as a package manager works best with a repository called "Nixpkgs".

Nixpkgs focuses on reproducible builds, that means that for the same inputs, you always are going to get the same binary output.

All of Nixpkgs are built using nixpkgs, and they don't depend on any library outside nixpkgs, including glibc and compilers.

That means that you can "lock" your packages into a version, and you ensure that it will run the exact same version and configuration in all machines that you install it, no matter the underlying OS or how old/new it is, glibc problems etc...

This is the power of Nix.

All of this can be done via a simple

Flake.nix -> define the system Flake.lock -> automatically generated, defines the exact version of nixpkgs among others.

(Can also be done via channels but flakes are better imo)

Nix runs alongside other distributions in various OSs, including OSX. (Windows is being looked at, do not hold your breath.)

The cross-platform capability of `flox` comes from our usage of Nixpkgs, which includes allowance for some of the differences between platforms and makes them less of an issue.

If some piece of software has a specific difference when run on different platforms and you rely upon that difference, then your need to use that platform in some way: native, VM, translator, etc. Nix does make it easier to manage, build, distribute, multiple kinds of software.

Flox environments leverage this same foundation to expose the same environment on multiple systems and we plan to work on this more. What in particular would you be looking for?

I think you're looking for Nix flakes proper! This is one of the promises!

Given so, this means many tools based on nix provide this too, though it's not as easily surfaced.

That doesn’t solve “works on my box” or reproducible builds

Developer environments should be cattle, not pets once you’re working with more than a few engineers

One way of thinking about Nix is like A Makefile on steroids. It will build what is needed for the right platform. It is also smart enough that you can add cache server and when it needs something that already is in the cache[1] it will download and use binary package seamlessly.

Those packages are built from the same sources with same (or almost the same) configuration options and for all intents and purposes should be nearly identical.

So while you use your devenv, it will download and use the right packages for your architecture, and if something is missing on the cache server it will build it locally.

Now as ARM Mac's are as popular as the intel ones, people are making sure that the packages build on both.

[1] nix generates a hash which is based on the package source code, compile options, architecture etc. and uses that for the lookup.

The Nix binary cache does x86_64-linux, aarch64-linux, x86_64-darwin, aarch64-darwin and maybe others. Every single package is different, but built from the same source. You won't be sharing binary cache even for python or other interpreted things since they depend on "stdenv" which contains bash.

But in practice it's really easy. Though if you're all into robustness you should probably test on the same arch you deploy to eventually.

Thanks for asking! I'm Michael Brantley, Flox CTO and formerly responsible for build and release engineering at the D. E. Shaw group. The high-level summary can be found in https://flox.dev/about but the back story is that I started diving into Nix in late 2017, and once I finally understood how Nix worked, how amazing the Nix community is and the incredible potential of the Nixpkgs collection I immediately realized I'd been "doing it wrong" all this time! It was then that we embarked on an effort to deploy Nix internally, but soon ran into many obstacles to enterprise adoption.

As I'm sure will be similar for many other teams, our Nix deployment started life as a series of bespoke applications and systems created to address such obstacles, but I suppose the difference in our case was that we had an internal venture studio called DESCOvery who recognized the impact that it could have on devs everywhere, and then worked closely with Ron, founding engineer Tom Bereknyei and me to launch the business. It's been an awesome journey - we hope you like it, and stay tuned for more to come!

Sorry you had a frustrating experience. It's definitely us missing the mark.

Re: fish, saw you found the issue someone else opened on it. We have it on our plan and will be adding support soon https://github.com/flox/flox/issues/1173

Re: your zsh experience, it's hard to judge exactly what's happening from your comment but we have had other users where the state of activation was suppressed by themes which can cause "environment already active". https://github.com/flox/flox/issues/637 - if you think it's something else or have more detail to share, let us know (either here, github, anywhere).

Thanks for trying Flox!

(Flox employee here)

`flox` needs Nix to function. So the rpm/dev/OSX installers first install Nix, and then installs flox itself.

If you have Nix already, you can try it out as described here: https://flox.dev/docs/install-flox/#install-with-existing-ni....

side-note: with further improvements to Nix as a library, it may be possible to make installing Nix not necessary for flox to function, but this is on a longer time horizon... don't hold your breath

That link in hub.flox.dev is wrong. The link at https://flox.dev/terms-conditions is correct. Fixing.... thanks!

Yes. We have designs to allow for more powerful configuration for experts. A good example of this is let people use alternative manifest representations; JSON, Nix, etc.

we will always allow the CLI to stand alone for a local developer or CI runner. the service side of Flox is for those who want a faster performance, easy sharing, or eventually enterprise control. so while the CLI can use the closed service it's purely optional (and will always be optional)

Thanks for pointing it out, it made me look closer at it.

I normally would actually welcome GPL, because it allows to keep project being open source.

Though looks like project also comes with CLA where anyone who contributes surrenders their copyright to FloxDev, Inc.

What this means, is that no one can fork it and make from it a commercial product. Many would say this is great as it can keep the project open source, except the CLA gives FloxDev, Inc. option to change license at any moment to whatever they want, including making the project fully closed source.

I don't think such project can be called open source. It feels like a Trojan horse to fool developers (kind of what Hashicorp did). I mean it is the right, but if you're contributing to it, you're not contributing to Open Source project but volunteering free work to another company.

Thanks for asking! This is definitely a deeper lets get beers convo when you're in the bay! But - Have you ever seen the Microservices video? https://www.youtube.com/watch?v=y8OnoxKotPQ

I was leading the developer products team at Facebook back then and started a project around injecting remote capabilities into local dev. Short of it was that thousands of developers were waiting 45 minutes for cold builds... Part of the initial steps for the project was to map out the entire SDLC (so we can get a sense of what parts of the toolchains we need to rebuild), that's where that video above comes into mind if you look at that whiteboard towards the end... Visualizing how complex we've made it is what got me into the headspace of - this can't actually be how we go about this.

Yes. For limited situations it provides a simpler interface. Flox won't provide exactly the same feature set, but there are many situations where home-manager is too much.

You can consider the current `flox` environment to be similar to a declarative profile, conceptually positioned between home-manager and devShells.

Flox employee here, you can do that by creating an environment in your home directory and activating it in your `.bashrc` or `.zshrc` (we don’t support fish yet, but it’s on the roadmap). An environment created in your home directory is called `default` and your question is exactly its intended purpose.

What's your story for dropping down into 'real Nix' if required?

We already have talked about this and plan to allow using Nix itself in those cases where someone needs the additional power. The current thought is to have allow a either a reference to a flake for specific fields or to have an Nix-style entrypoint.

This is not yet exposed or documented. Stay tuned.

aside: absolutely agree that there is a fine line between hiding complexity and exposing power