Document system.build.toplevel #155883
Document system.build.toplevel #155883
Conversation
Extracting system.build into its own module allows other modules that do not depend on e.g. toplevel to be evaluated, used and tested in isolation.
This allows the values below it to be specified as options, while remaining compatible with existing code.
roberth
changed the title
github-actions
bot
added
6.topic: nixos
|
Why is this blocked on #146882? Submodule types can be merged IIRC so you should just be able to do # nixos/modules/system/activation/top-level.nix
{
system.build = mkOption {
type = types.submoduleWith {
modules = [{
options.toplevel = mkOption { ... };
}];
};
};
}What do you mean by " |
This PR does not evaluate: This behavior could be considered an artifact of the module system's development history, but if you stop squinting, it's a bug :) |
|
Sure, but it doesn't block the PR in that we can just comply with the quirky module system for now |
Right, but we'll be creating a mess and setting a bad example of useless complexity. In this case I'd rather wait. Maybe I am using "blocked" too liberally. |
|
#156503 needed some of the same changes, so I've included it there instead. Closing. |
Motivation for this change
system.build.toplevelisn't internal anymore, so it should be documented. For example the Flakes article on the unofficial wiki mentions it. It is a very important interface, so I don't think we should try to hide it.Blocked on #146882
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)nixos/doc/manual/md-to-db.shto update generated release notes