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