tomberek

The ability to quickly try out and verify ideas is valuable. This would have taken immensely more time to get to a stage to reasonable verify or dismiss as an idea otherwise. This saves time for builders.

The author cares; this is not a post-a-quick-project-as-slop-to-get-cred situation.

The Nixpkgs Core team was established in Sept 2025 (https://discourse.nixos.org/t/establishing-the-nixpkgs-core-...), so it is a fairly new concept and idea. They've accomplished some good things as highlighted in the post, but are now stepping down. Yes, we'd prefer for the team to exist, but we've also functioned without one for ~20 years. It may take multiple iterations to bootstrap the concept and to figure out the right structure - or we may find it isn't needed. So no, this is not a critical emergency. It's a return to the status quo of late last year.

That being said, I think it is still a concept worth pursuing.

Perhaps give boats some advantage in capacity.

Presumably this would support a big improvement to both SBOM generation as well as various UX features and workflow improvements.

Trading perfect reproducibility for usability: a pragmatic look at Flox's new features

This is exactly how I can rapidly prototype things. Once proficient with this tooling is becomes very easy to quickly spin up services and PoCs. Managing it and iterating is also a breeze.

Random thought. Another commenter worried about the runtime of the program becoming mangled and performing destructive operations on your machine. What if you run the reducer as a source-to-source Nix derivation? Protects against dangerous things, and can be easily distributed to remote builders.

Agreed. Packaging is different than deployment. Devs should return to the art of packaging, such that their software can be then deployed into containers, VMs, micro VMs, whatever. That is what packaging allows, re-use.

This is the sort of behavior Nix encourages (disclaimer: I work at https://flox.dev , using Nix as our baseline tech). Docker as both a packaging and deployment format can carry a bit of weight, but can quickly get out of hand.

This is excellent. Have you considered making a presentation or a write-up of the experience?

A similar article for bringing Ruby into the Nix ecosystem: https://flox.dev/blog/flox-and-ruby

This is an excellent pattern. Nix uses it to allow one to create a full transitive build graph, serialized that plan, move it around, and execute it in a distributed and reproducible fashion.

There are always temptations to loosen the constraints this imposes, but they nearly always come at a cost of undermining the value of the pattern.

`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!

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.

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.

Yes, I'm also a Nix maintainer. `nix develop` does many other things, originally based on re-creating the build environment of a derivation. This means that it is not ideal for the case of development environments that must support more than just building.

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.

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

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

> 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