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

[Jan Malakhovski]

Hi,

On Fri, 21 Feb 2014 17:18:10 +0100
Eelco Dolstra <eelco.dolstra at logicblox.com> wrote:

> 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

Yeah, I thought about it and convinced myself that that's manageable
(see below).

> > 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.

Yes, and that's okay. I'm against the idea that ISO images are somehow
NixOS systems (e.g. they set grub.enable = false). Philosophically,
they are a very different type of a system. But it's okay to
generate them with the same general mechanics (evalModules).

> > 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.

Yes, but, again, philosophically I would rather have something like

* boot.loader.enable = false when I don't want to mess with any boot
  loading at all,
* boot.loader.grubStatic.enable = true in iso-images and on a static
  system, and
* boot.loader.grub.enable = true on a usual NixOS system.

> > * 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.

I'd like to have a way to differentiate between build.system.toplevel
and systems without their own kernel not by just ignoring their
kernel.

> 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).

Yes, my rants have nothing to do with the issue, but the code I wrote
(and posted in the previous message) to mitigate some of the stuff in
the rants is more than somewhat related to the issue. E.g.

https://github.com/oxij/nixpkgs/blob/show-some-work/nixos/lib/nixos/bootstrap.nix

Even after a week of thinking I still like the general idea there.

Cheers,
  Jan