Hello.
I’m trying to improve my darwin nix configuration and I’m trying to make some modules.
In this case, I have one module that depends on another one to be active, so if module A is deactivated, then module B should deactivate too.
However, in order to make it work I had to define the option on both modules, making this easy to get out of sync.
Is this the way of doing it?
To be fair, I don’t know what to expect in the params of my module, because I don’t know what module system it is using. Is it normal nix module? Is it imported by home-manager? Is something else I have no idea about?
The fact that I don’t get any editor help like go to definition or find usages only makes this worse.
It does seem like you’ve written some modules to be for nix-darwin and some for HM. It’s probably better if you keep them more separated. (Anything imported transitively from home/default.nix, given how your repo appears to be structured, is an HM module; and anything imported transitively from your darwinConfigurations is a nix-darwin module.)
I don’t think either of your two new modules need to be nix-darwin modules — it looks like they only ever impact HM options. But ubersicht.nix is written as a nix-darwin module and should probably be an HM module instead. And then you’ll only need to define the programs.ubersicht.enable option once, because you’ll only be using it in one module space.
That makes sense, as they are just things that I want to use in my personal computers at the user level. How do I define them as HM modules? What are the requirements? Should I import them differently?
My repo is a bit of a mess because I started writing it at the same time I was learning Nix. But given the amount of options to layout nix module, I’m not sure if I would be able to do it better starting from scratch today.
By transitively you mean that I import from home-manager root, and then tose modules import other modules, right?
If you have any advice I will be more than happy to take it, as I’m very unhappy with my current layout and way of defining hosts configurations.
By and large, the only things that need to change between a module of one type and the other are:
what other modules are allowed to import this one, and
the set of options the module can define.
(If you’ve gone messing around with special module args, those will also vary. I’m not a fan of leaning on that mechanism for ordinary data-sharing purposes but I have no idea if I’m in the minority.)
Yup, exactly.
I recommend keeping each of the different varieties of modules separate. I’d suggest one top-level folder for each different variety of thing:
home ← contains all, and only, Home Manager modules
darwin ← contains all, and only, nix-darwin modules
darwin/hosts ← these are modules too, so they go in here
nixos ← contains all, and only, NixOS modules
nixos/hosts ← these are modules too, so they go in here
lib ← contains utility Nix functions or constants that can be vanilla imported by modules, but contains no modules (I don’t know if you have any of these)
pkgs ← contains Nix package definitions that can be callPackage’d by modules or overlays
overlays (if you have any)
files
Keep module imports (the imports = [ ... ]; style) to within a single top-level directory. Permit vanilla Nix imports (the import ... style) from {home, darwin, nixos, pkgs, overlays} to utils, and from modules to a root module of another variety when needed (for example, when a common darwin module that defines users imports the root HM module for a user).
Resist the urge to define polyglot modules that will work in multiple top-level module flavor directories. Factor any intolerable duplication out of the module system and into plain-Nix files in lib. This is not necessarily the opinion shared by many people but I think it’s good advice.
This last bit is mostly aesthetic, but I try to keep my folder structures uniformly two-deep. I always make nixos/foo/default.nix instead of nixos/foo.nix, and nixos/foo_bar/baz.nix instead of nixos/foo/bar/baz.nix. That way, relative import paths (of whatever variety) don’t need a lot of thought: ../../foo always points to a different top-level folder, and ../foo always points to another grouping in the same top-level category.
Because one is a plugin for the other. So, you may want to enable the plugin, but I’m not sure that the sole act of enabling a plugin makes you want to enable the entire module. But it may made sense. How would you do that by the way?