I mean.. it sounds wrong[0]. I don't think flakes are really mandatory given that the status quo is stuff like brew, but home manager actually does "the thing" that Nix people are talking about. Without something like home manager or NixOS, you really are only halfway to what the actual pitch is for nix.
(Aside: I can't imagine figuring out how to use nix just from the official documentation. Those documents are a total mismatch from what the audience needs, focusing way too much on how to write your own custom modules, and not nearly enough on actually consuming them or decent patterns for it)
[0]: people are allowed to do what they want. But the path chosen by this author is not the easy path
> I mean.. it sounds wrong[0]. I don't think flakes are really mandatory given that the status quo is stuff like brew, but home manager actually does "the thing" that Nix people are talking about. Without something like home manager or NixOS, you really are only halfway to what the actual pitch is for nix
I agree— I really like NixOS-like module systems and how they merge together different bits of config to bring the benefits of Nix to configuration management. Being able to configure the whole OS or a big chunk of it via Nix, including running services, managing users, pre-configuring various programs, and more, from a unified interface in a simple language like Nix is awesome.
Declarative package management is great but the broader configuration/service management stuff is even better.
> Aside: I can't imagine figuring out how to use nix just from the official documentation.
That's part of what makes Ian Henry's blog series on the topic compelling! Nobody really learns it that way, and so he's putting the docs to an unusual and much-needed test. Definitely check it out :)
I really like Nix's configuration language too. It seems to hit some sweet spot where it manages to be simple, expressive, versatile, and maintainable, all at the same time. So I find it sad when I see people almost instinctively dunk on the language. I wonder if recent efforts around documentation can improve things.
I think people just (understandably) have little patience for new DSLs in general.
Another thing that I'm realizing is awesome about Nix as I'm getting my feet wet with CUE (also an interesting configuration language) is that in a way, the power of Nix makes it easier to learn than it otherwise might be.
So much of what we actually do with Nix leverages functions and libraries that are written in Nixlang, stored in the same monorepo as all of our build recipes. This means that once you get more familiar with Nix-the-language from using it in your own configs, exploring the implementations of the tools you use in building your packages and environment becomes easier and more natural. And Nixpkgs is then an awesome one-stop-shop for countless examples, and even kind of a quick reference for how a bazillion different pieces of software can be configured.
Maybe it's an acquired taste, idk. But I feel like the language is great at being simple when it can and surprisingly flexible when it needs to be. And Nixpkgs becomes a great resource for users, once they learn some of that relatively simple language.
(Aside: I can't imagine figuring out how to use nix just from the official documentation. Those documents are a total mismatch from what the audience needs, focusing way too much on how to write your own custom modules, and not nearly enough on actually consuming them or decent patterns for it)
[0]: people are allowed to do what they want. But the path chosen by this author is not the easy path