Thanks @jacg for the feedback - flox wouldn’t be possible without Nix and countless other open source projects, so we’re thrilled to give back to the open source community by sharing flox. For now we’re just asking for everyone’s patience and feedback as we navigate the [mostly legal] intricacies of a new project. With respect to open sourcing, all options remain on the table as we work to figure out the next steps in our journey.
Whatever form flox may take, I hope it will at least provide a fresh perspective on architectural issues that I think may be hampering Nix adoption. In my experience these were the key design choices that made it possible for us to deploy Nix at scale:
- Centralizing all Nix processing and state (including profiles) on a single pair of fault-tolerant “storehouse” servers
- Creating a “nixexprs” framework for managing/simplifying Nix expressions in an enterprise setting
- Providing automatic and effective CI/CD
The first of these is simply an idea/architecture, and it’s not even unique - I recall listening to Pierre-Antoine Bouttier at NixCon 2018 as he described the GRICAD HPC center’s approach of sharing out /nix as managed from “head” nodes over NFS, and wondering why more people didn’t deploy Nix in that way. The second is available for all to explore on the flox beta, and the third is just Hydra as driven by our “nixexprs” framework.
… and that’s it really. Of course, while this approach has worked for us it may not work for everyone, which is why we want to work with the community to figure out how flox can help Nix gain a foothold in more companies.