> The configuration.nix "defines" the whole system, but obviously doesn't touch anything in /home

https://github.com/nix-community/home-manager

> or /var, so that's on you to back up, migrate, whatever.

https://grahamc.com/blog/erase-your-darlings

https://github.com/nix-community/impermanence

You can't get rid of all state. The pros/cons of a Nix approach is that it is far more explicit about what is pure/impure. This experience is similar to going from a dynamically typed language to a stronger type system; it can be frustrating to be told that something is not allowed. Nix's usability difficulties often come from trying to build or use software that violates purity in some way (reading HOME directories during compilation, using the network in some way, assuming a dependency will "just be there"); it prevents these mistakes at the cost of forcing the person doing the packaging to fix these issues. This is a huge benefit in the long-term, but can annoy short-term uses.

I'm so confused-- there's a user upstream reporting something about having to grep for a variable name, then having to grep for the function that created the variable just to figure out the type.

Are they using Nix wrong? Or is this seriously a limitation of the current state of the tooling?

If it's a limitation of the tooling, that almost sounds like satire. I.e., someone builds a powerful functional DSL, uses it to painstakingly construct a monstrous package graph, then gets tired and wonders, "Wouldn't it be great if there were a language and data structure that were both custom suited to automating the grep'ing of argument types for my DSL's package graph..."

Many of the necessary fixes do end up getting pushed upstream, though, thinking especially of stuff like converting CMake projects to use the GNUInstallDirs standard, so there is a benefit to the strictness work that extends beyond even just the Nix community itself.

Of course, sometimes those kinds of changes just never get merged, for a variety of well-understood open-sourcey reasons, eg: https://github.com/pocoproject/poco/pull/3105

What are the well-understood reasons? It seems weird to me, as someone who hasn’t worked on open source, that the PR would just sit there untouched and not even commented on

I'm not seeing an easy reference right now, but I feel like a number of articles bemoaning the state of open source maintainership have come up over the years, particularly in conjunction with high profile security issues like the ones in the OpenSSL and log4j projects.

But in short, the maintainers are mostly uncompensated, and therefore have no sense of urgency or obligation to a faceless stranger making a drive-by contribution. Every accepted contribution is something that has to be understood, supported, and even justified by the project's maintainers going forward, so each one is an opportunity to take on more work and risk, and obviously by definition almost all them are things the maintainers didn't themselves "need" or they would have done it themselves. So each new branch or bugfix is relevant to a codepath that no one involved in the planning, testing, or release-preparation for that project has a first-class stake in. Each new capability added is an opportunity for there to be shrieks following a release because it was inadvertently broken in the course of some other bit of development.

And now that PR is merged...

Well yes. I wasn't intentionally shaming the poco project with the link, but having a bunch of attention drawn all at once does have a way of moving these things along.

That's true. I guess I see it as the difference between the system and what I'm doing with the system—it's like having a database system where I'd want the config for the database to be totally reproducible and immutable, but I'd expect to manage the data itself separately.

And, as a practical benefit, I found setting up borg backups for /home on NixOS a lot easier than I expected :)