We are currently evaluating nix as an replacement for our internal build system, our main product is some kind of linux distro.
Nix has real bad onboarding and documentation, the creators hopped off to some other, shinier side projects (flakes) and the rest of the community is struggling to manage the immense maintenance cost of keeping the packages up-to-date and integrated. And the external consultants we hired for it are like, hardcore believers that always tell you how great nix will be in the future, but completely disregard our needs like building offline in a separated network. Which is officially supported but unusable to due bugs.
Disclosure: I love Nix ecosystem, but I acknowledge the fact that it's perfect for my use cases which are very different from those of a business.
> Nix has real bad onboarding and documentation
Could not agree more. I found that diving into it head first actually did yield good results in the end but it was really not quick.
> some other, shinier side projects (flakes)
I would argue that flakes are an absolute necessity and logical continuation of the ecosystem development rather than a side project. Flakes allow to truly describe the desired state of the system from one place and properly pin all objects to their places.
What makes you think flakes are a shinier side project? In my opinion, flakes are the One-True-Nix at this point. They simplify a large swath of issues with using Nix, and every day that sees flake adoption improve is a net-win for Nix usage overall.
Its nothing to do with a world religion, its correcting what I see as a flawed view that flakes are somehow something unrelated to nix and the issues involved with nix, and that time spent on flakes is time wasted from a nix consumer POV. I'm telling you that not only are flakes a main-project for nix developers, but that they serve to completely upend how nix is used. As I said, flakes directly solve several issues of nix-without-flakes. This is a huge benefit for the nix consumer.
flakes is not a side project, it adds to the nix model, doesn’t supersede it. It is basically a lock file for a package, making it easy for anyone, even a separate repository not related to nixpkgs at all to reproduce said build with compatible versions.
