What's the difference between this and just using a default.nix/flake?
At the most trivial level, you can set up some packages to install [1][2]. You'll generally come out ahead of classical package managers if you do that and nothing else.
Nix also acknowledges the configuration issue. Think of this like copying some config files using a dockerfile. You can either use literals[3], or use the nix language to generate the config [4] (provided that someone has created the required projection from nix to config).
What this ends up becoming is a single git repo with your entire system setup. My repo gets a bit fancier: I have my home desktop (currently Nixos, but it distrohops a lot), my personal laptop running Ubuntu+intune+nixpkgs for work, and then my work Mac machine (which I am aiming to get rid of). The single repo contains nix configs for all 3, and shares config where appropriate.
I really need to write a blog post about Nix in 2023. The main issue with getting started right now is that the installer requires some convincing to use flakes (not to mention that flakes are disabled by default), and you really should be using flakes.
[1]: https://gitlab.com/jcdickinson/nix/-/blob/main/system/jono-d... [2]: https://gitlab.com/jcdickinson/nix/-/blob/main/home/general.... [3]: https://gitlab.com/jcdickinson/nix/-/blob/main/home/general.... [4]: https://gitlab.com/jcdickinson/nix/-/blob/main/home/dconf.ni...
> Don't worry: You can use Devbox without needing to learn the Nix Language.
There's been some experimental work towards this end for a long time, once under the banner of a 'service abstraction layer' for NixOS, and more recently Sander van der Burg's 'Nix Process Management Framework'. But right now, none of the mature module systems are 'universal' in the sense of being usable in all of the many environments Nix can run in.
If you were going to roll your own solution, imo using the latter of those efforts (nix-processmgmt, probably backed by supervisord) in a flake.nix or shell.nix seems like a sensible way to go. At the same time, I think using devbox to wrap all that config looks like a pretty nice way to go for teams or projects that don't already have much Nix buy-in.