add hosts module arg

[Pacman99]

should help with #163. Fixes #169
But either way this could be generally useful. I have one use case of setting up a minecraft bungeecord proxy with servers on different hosts.

[nrdxp]

This looks fairly benign, perhaps a usage example in the docs would be pertinent

[Pacman99]

Agreed a usage example would be nice. I'm not sure where to put one. This change could be useful for profiles, modules, and hosts. But I guess hosts would still be the best place to include it.

[nrdxp]

Actually, I was wanting to add a section to the docs, something like Common Usecases or something to that effect. Perhaps it would be best there.

[Pacman99]

Yeah that would be perfect

[Pacman99]

If we do add multiPkgs in the other PR, we could document both as special arguments available to hosts.

[Pacman99]

switched to use _module.args based on comment in nixpkgs/lib/modules.nix. hosts arg should never be used in an imports line - evaluated modules can't be imported again,.

[Pacman99]

I increased the scope of this PR to cover #169. Now lib functions can access self and any input. And inputs is passed as a special arg, since that could be used in an imports statement. Self is passed as a module arg since I can't see a reason to why it would be part of an imports statement.

[blaggacao]

LGTM

I think it might be still too early for a smdocumented usage example. As I understand it, this idea came up towards a possible way reacting to another hosts configuration. That is mostly it's identity (hostname, ip, systemd machine id, — maybe static link local ipv6?)

I think you need to rebase?

[Pacman99]

Yeah exactly, although with self and inputs I think this PR has more value. It is now an alternative method of passing inputs to your hosts instead of extern. So for mobile-nixos you can't use the extern modules section, because you can't add the pinephone module to all hosts. So using the inputs specialArg would be better. You can also use self.packages for cross compiling.

I don't know much about wireguard, but I would imagine that you might need to know information about other hosts to create the config for each host.

[blaggacao]

I carved out the self part in #189 so that we can reason about inputs and hosts independently and also to unblock #168

[Pacman99]

I think either way we're blocked due to the ci issues. And I think this PR is pretty much ready to merge.

[Pacman99]

I was debating over doing this or just making it available as inputs. I prefer this way so a lib function could just do something like { nix-darwin, ...}: and get access to nix-darwin.
The alternative would be { inputs, ... }: inputs.nix-darwin.lib.darwinSystem

[Pacman99]

And also a lib function could do args@{ ... }: and remove pkgs self and lib to get access to all inputs. This is probably only useful for #190

[blaggacao]

Maybe let's keep it name spaced as inputs. Similar to self this is well-known self-explaining top level flake glossary.

[Pacman99]

I personally prefer this method because it feels more in alignment with the callPackage paradigm - or in this case callLib. You specify the things you need for your function and you get those inputs. If we just pass inputs itself, then you take everything, which is more similar to the module system.
But I'm ok with either, they both get the job done.

[blaggacao]

hm, for the sake of consistency, we probably shouldn't import it differently than how we import it with ./hosts, though.

[Pacman99]

hm, for the sake of consistency, we probably shouldn't import it differently than how we import it with ./hosts, though.

But do we really need consistency between lib and hosts? they are two different things.

@nrdxp Which one would you prefer? I think once decide how to pass inputs to lib, this should be ready.

[blaggacao]

nix.registry = mapAttrs (n: v: { flake = ${v}; }) inputs; look clearer, indeed 😉

No need to be aware if some additional unwanted attributes sneak in and cause nasty side effects in unexpected places.

(over: nix.registry = mapAttrs (n: v: { flake = ${v}; }) (removeAttrs inputs [ "self" "pkgs" "lib" ]);)

[Pacman99]

So this PR now only covers passing inputs to lib and hosts. And it adds the hosts module arg as a convenience.

[blaggacao]

Do we actually want to pass inputs to ./hosts? see #190 (comment)

[Pacman99]

My reasoning is theres no harm in doing so. And it helps with flakes containing nixosModules that you only want in one host.

And extern doesn't cover all use cases with inputs and having inputs part of the module system accounts for pretty much any use case.

[blaggacao]

And it helps with flakes containing nixosModules that you only want in one host.

Is this an issue despite lazy evaluation? (sorry my ignorance)

And extern doesn't cover all use cases with inputs

Did you have any specific use case in mind?

My reasoning is theres no harm in doing so.

Well, it dilutes the interface. I don't think that's good on such a general basis which affects ./profiles and ./modules downstream. Or at least we should have a clear picture of what our interfaces are here.

I mean all of a sudden, we have to ways to accomplish the same. This is a recipe for trouble.

EDIT: Until we have our interfaces sorted out, I'm leaving the ./hosts parts out for now in #191

[Pacman99]

I removed that part. I realize its a pretty niche use case and also I can just do it manually in extern with an inherit inputs;.

[blaggacao]

Thank you @Pacman99 for all this inspiration and thought fodder.

Interaction / discussion has it all! ❤️

[Pacman99]

Thank you @Pacman99 for all this inspiration and thought fodder.
Interaction / discussion has it all! heart

Indeed it does! Thank you too!

[Pacman99]

Also this is back to its original state, just adds hosts module arg. So I think its ready to merge.

[nrdxp]

bors delegate+

[bors]

✌️ Pacman99 can now approve this pull request. To approve and merge a pull request, simply reply with bors r+. More detailed instructions are available here.

[Pacman99]

bors r+

[bors]

👎 Rejected by too few approved reviews

[nrdxp]

bors r+

[bors]

Build succeeded:

• ci/hercules/derivations
• ci/hercules/evaluation