[Nix-dev] Fixing module arguments (PROPOSAL MAY BREAK EXISTING NIXOS CONFIGS, PLEASE READ)

[Eelco Dolstra]

Hi,

On 20/02/14 00:06, Jan Malakhovski wrote:

> * generate a live CD with a _set_ of configurations squashfsed
>   together with a common grub loader
> * generate a set of configurations that are to be booted through PXE.
> 
> This all is more than "somewhat untrivial" with current design of
> NixOS. 

The design of NixOS actually makes these things pretty easy.  It's just that
nobody has implemented them yet.  (Actually, there was a way to define multiple
"sub"-configurations accessible via GRUB, but it got lost a while back when I
reimplemented the GRUB menu generator.)  For instance, the NixOS option
systemd.containers allows you to define a set of NixOS configurations to be run
as lightweight containers via systemd-nspawn.  The implementation was pretty
straightforward:


https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/virtualisation/containers.nix

> I want to be able to differentiate between NixOS outputs. Currently
> "system.build.toplevel" is more or less the only output NixOS produces
> directly 

There are in fact plenty of other outputs, such as system.build.isoImage,
system.build.amazonImage, system.build.virtualBoxImage, and so on.  I don't
agree that these are "hacks" - they are values that get computed from the rest
of the system configuration, just like system.build.toplevel, and you can new
ones via modules.

> I want a way to generate (I meas, by construction, "well-typedly", so that
> configuration.nix has no meaningful way to get around this)
> 
> * a system without the control over the boot loader (think liveCD with
>   a common loader and a set of systems on it, or a PXE-booted system)

If you set boot.loader.grub.enable to false, then NixOS won't mess with the boot
loader.

> * a system without the control over all the stuff that happens before
>  activation, e.g. kernel version.

This is also possible.  For instance, NixOS containers don't have a kernel or an
initial ramdisk - they're booted directly into the stage 2 init script.

In any case, I don't think this has anything to do with the issue Shea raised
(the problems with the "pkgs" argument to modules).

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/