Thanks for suggestions.
I’ve been working with nixd for quite a long time.
But I think thing that wrong is comes from the flake design itself.
Raw and annoying design, have to mix with lots of utils and template scripts, which may my feel uncomfortable.
Why i have to use flake-utils, for so many years?
It should be built-in with flake, but not a common function make flake.nix more ugly
You don’t have to. The only reason to use it is to replicate package entries for multiple system tuples.
The initial flake design was built the way it is with the reasoning that ignoring system tuples like most projects and build tools do leads to Schrödinger’s cross-platform support - all projects do and don’t support all platforms until you try building for that platform.
So, the design of flakes forces you to specify the tuple. In theory, this means you have tested building against that platform, and are actually aware of it. In the C world, supporting another arch often means changing the build a little anyway. I’m actually quite fond of this idea.
Now, many people don’t understand the intent and feel compelled to advertise that they do in fact support every platform under the sun when they actually don’t. Really, most flakes should only list x86_64-linux.
There are also many languages which actually don’t care much about the platform (e.g. python scripts) and can be written in a somewhat platform-independent way (somewhat, import os still presents challenges even there). So there are a small handful of projects that actually would like to not care.
I’d suggest thinking about whether you actually use this correctly. I suspect most projects could just alias system = "x86_64-linux" and be totally fine; better in fact, since you’re no longer falsely advertising what you support.
That said, yeah, there are also projects which definitely don’t care, and the flake design doesn’t cover their use cases well. flake-utils is an escape hatch for those, but this is an inherent design flaw, and probably actually the main point of flakes criticism (because it is so visible and so few people understand the intent, mainly because the docs are lacking IMO, which in turn are lacking because flakes never evolved out of their experimental state).
The reality is, the flakes concept is not ready. Political and financial constraints are smothering its completion. It covers too many disjoint things that nix needs, but the inertia of doing so many things at once is making it hard to complete this. It would have been better if each of the problems had been tackled over time (i.e. flake output standardization without pure eval, pure eval without the flake schema, improved CLI without everything else, input management without …). Sadly we don’t live in that world, and it will take years to resolve the fallout, if it ever does get resolved; there doesn’t seem to be much energy left for that.
Don’t use flakes, especially as a newcomer, unless you have a good reason to. If you want to pin your inputs (which I encourage!), use npins. As a newcomer, you likely don’t need - or are aware of - any of the other things flakes provide anyway.
I use nix and home manager to manage system configuration and commonly used packages over multiple pc /dev machines, over aarch64/x86, mac and Linux, that’s why I have to get trouble into the flake utils.
Well, the new designed nix flake command brings many benefits actually, but flake itself is really a mess.
I am considering remove it from my system completely, since it bring more trouble than benifits and slowing down darwin-rebuild and direnv reloading.
thank you for your explaining in such detailed