`FLAKE` is not a very specific env var

[dpc]

I just watched https://www.youtube.com/watch?v=DnA4xNTrrqY and I like the idea.

FLAKE is a very generic name for an env var and I'd prefer something like NIXOS_CONF_FLAKE or NH_OS_FLAKE (good practice to prefix globals like this with a name of a tool).

[viperML]

I've had NH_FLAKE in the back of my mind, but at the same time haven't found any project that also uses FLAKE. Perhaps it is possible to parse both from the environment, with priority to the former

[dpc]

Definitely possible. I thought about _OS_ if nh was to handle more stuff. I don't know if that's the plan. One might have "NixOS configuration flake" and then some other flakes.

[Adda0]

I agree that something like NH_OS_FLAKE or even NH_NIXOS_FLAKE, and maybe in the future NH_<OTHER>_FLAKE would be a great descriptive and conflict-free solution.

However, if I am not mistaken, one could use nh on non-NixOS system for, for example, managing their home manager configuration flake. So maybe something like NH(_MAIN)_CONFIG_FLAKE or similar to make the name of the env var more general, yet still descriptive?

[viperML]

You can use wrapper-manager to wrap nh and not pollute the global environment

[Adda0]

That is a very interesting project indeed. This approach would solve this issue for me.

[x3rAx]

I'd love to see something like NH_OS_FLAKE and NH_HOME_FLAKE used by the commands nh os and nh home respectively, with a fallback to a general NH_FLAKE (or just FLAKE or whatever) when the command specific variable is not set

Or maybe don't use NH_FLAKE at all and simply support FLAKE just for backwards compatibility, since I don't know of a way to have the os/home config in the same flake other using the "home manager in system config" approach. But I guess in that case, you can't build home manager independently fom your system anyways?