The other idea is to have home-manager and NixOS options in the same file.
For example the droidcam package has an option from NixOS but the option doesn’t create a desktop file.
I would like to create the desktop file with home-manager and add it to the same .nix file as the NixOS option so that all the droidcam options are in the same file and I only need to add one import to enable droidcam without having two configs one for NixOS and one for droidcam.
pkgs.lib.callPackage will call a function, giving it all the named arguments from nixpkgs it asks for. There are variants of that function that allow you to specify additional/your own scope. Whenever you specify a derivation, using that is a very nice way to achieve this.
For modules this isn’t possible without serious hacking, so using the let inherit ... in pattern is probably the nicest way to achieve the import clarity you’re looking for, combined with the assignment @cab suggests when you need to rename.
Note that glob imports in Python are mostly discouraged because Python scoping is a mess. Nix isn’t affected by this, so it’s significantly less problematic here, although I agree it’s nice to explicitly state your imports just to make it easier to read. The conventions here probably come from the Haskell world, where glob imports are almost encouraged.
This is possible using the NixOS module. Note that this is a completely separate tree under config, so there’s no need for a renamed import or anything.
I think you have the scope a little backwards. The purpose of the ... is not to bring into scope variables like networking or virtualisation. When you write networking.hostName = "foo";, you aren’t using a variable named networking. A NixOS module is a function that takes certain inputs, and returns an attrset (think dictionary) of configuration definitions. So networking.hostName = "foo"; is actually saying that the attrset returned by this function should contain a key “networking” whose value is another attrset with a key “hostName” whose value is “foo”.
The purpose of the ... is that the NixOS module system provides a bunch of typically unnecessary arguments to your module, so we use ... to say “the system can give me whatever it wants; I only care about the ones I’ve listed here, like pkgs.”
Note that the NixOS module system is a very different system than the callPackage system used within nixpkgs.
Thanks I’ll check it out.
But I think understand it now already a bit better.
I’m reading (or read already) a lot of resources (nix pills, nix tour, NixOS manual, etc.) but I’m having some difficulties to understand what parts are relevant at which location or for which task.
Another reason to have the ... in module arguments is it allows us to add additional arguments in the future without rewriting every NixOS module in the world. Also, the module system allows you to have your own custom arguments, though that is a rarely used feature (I think).