ENH: Support home-manager (`nix-build` ?)

[kai-tub]

Hey.

This project looks quite interesting. Thank you for working on it!
I played around with the project to get nix on a locked-down server and would like to know if it is possible to install home-manager.
I am following the official home-manager documentation -- nix flakes with nixos-stable as the target.
When running the rebuild ./nix run .#homeConfigurations.<name>.activationPackage I get the following error message:

/nix/store/j333lfi0wk1f2yd1bg2qnrp0hp43cway-home-manager-generation/bin/home-manager-generation: line 68: nix-build: command not found

If I understand the README correctly, the idea is to link all nix command calls to ~/.cache/nix-static.
So I linked nix-build to nix-static and added it to my PATH at the top of my bashrc.
Though, I still get an error.

I am not that experienced with the internals of nix but if you give me some pointers, I will try my best to help with this issue :)

[Thesola10]

Nixie wasn't designed with system-wide use in mind. The reason you get the errors in Home Manager is due to a quirk with the way rootless Nix (and by extension Nixie) works, in that the nix command isn't "installed" in the chroot environment.

You can add a few lines to your .profile to zip your entire session in bwrap with the /nix directory at root, then install Nix the usual way, but then suid binaries won't work.

Nixie being designed to work in a per-project ecosystem, where whole-session or whole-system management isn't required, this issue is currently out of scope.

In the future, I could build upon Nixie to enable session-wide installs (such as hooking into profile generation to provide redirectors in $PATH), after all most of the required tech is already in Nixie.

In the mean time I'm of the opinion that Nix is best enjoyed when installed across the system. Quite a few features (like multi-machine builds and result links) don't really work when running sandboxed, not to mention system utilities installed through Nix wouldn't work.

[Thesola10]

If you are interested in implementing a session manager using Nixie, here's a couple pointers:

• Nix loves symlinks. When you "install" a program using Nix, you actually tell Nix to rebuild the profile (which is also a derivation) with the new package in the list. A profile is an overlay of package layouts with symbolic links pointing to their real paths, as a quick ls -l ~/.nix-profile/bin will show you.
• Nix and everything it does rely on the /nix directory existing at system root, and therein lies the whole issue with developing Nixie in the first place. Root directories (usually) require root privileges, so the only other way is a container or sandbox. Outside the sandbox though, all profiles, result links and programs will break due to the missing path.
• Nix LOVES symlinks. You'll find symlinks pointing to other symlinks in the store, so you absolutely have to have a way to recursively resolve all of them when the sandbox isn't there. Just pointing to the real store may not be enough, as evidenced by the complexity of fakedir

I'm thinking hooking into profile generation, and rewriting the links to point to the "real" Nix store (for files) or to the wrapper script (for binaries).