[Nix-dev] NixOS: hardware based configuration.

[Nicolas Pierron]

On Sat, Jul 26, 2008 at 19:55, Nicolas Pierron
<nicolas.b.pierron at gmail.com> wrote:
> On Sat, Jul 26, 2008 at 03:58, Marc Weber <marco-oweber at gmx.de> wrote:
>> Another config would be qemu-with-sound-and-network or such ?
>
> Yes, as this could be interpreted as a device, there is no reason to
> omit it because this may interest a lot of people.

May be the best way would be to really split up everything instead of
having the file system/options.nix which contains a huge list of
options.  The idea is to consider software as a kind of a device with
options.

Each software have an associated set of options which is express with
more basic expressions.  For example the HAL daemon is intrusive
inside the arguments of the UDEV upstart-jobs.  It would be better to
have no intrusive code inside the UDEV arguments to keep each
jobs/device separated and like inside NixPkgs.

The following example is related to the job that I am trying to add on
my laptop to enable PCMCIA.

.----------------- pcmcia.nix
| this: # set of the concatenation of all configuration files.
| pkgs: # as described in the other thread started by Marc Weber.
|
| let
|   # Build the pcmcia derivation.
|   # if the nix-expression was made with "lib.sumArgs"
|   pcmciaUtils = pkgs.pcmciaUtils {
|     config = this.config;
|   } null;
| in
|
| {
|   services = {
|     # Define the new set pcmcia with two options.
|     pcmcia = {
|       # This option is used to ""extend"" or not the UDEV configuration.
|       enable = pkgs.lib.MkOption {
|         default = false;
|         # define how to merge multiple occurence of this attribute.
|         merge = pkgs.lib.mergeEnableOption;
|         description = ''Enable PCMCIA.'';
|       };
|
|       config = pkgs.lib.MkOption {
|         default = "";
|         # How to merge configurations.
|         merge = pkgs.lib.concatStrings;
|         description = ''
|           Memory & Port & Irq that can be allocated.
|         '';
|       };
|     };
|
|     # express the pcmcia configuration by ""extending"" the
|     # udev arguments if the PCMCIA service is enabled.
|     udev = if this.services.pcmcia.enable then {
|       addUdevPkgs = [ pcmciaUtils ];
|     } else {};
|   };
| }
`-----------------

This nix expression looks like the previous one defined except that
options are defined with this one.  These options are directly used to
extend the arguments of the UDEV job.  Therefore the concerns of the
UDEV jobs and other jobs are separated.

The look back set called ""this"" is similar to object programming
where the final object is the whole configuration of the computer
which is partially defined in this expression.  This is an extremely
powerful feature enabled by the laziness that will only retrieve
attributes that are used.

This way of writing the computer configuration can keep a very good
separation of concerns which leads to clean and maintainable code for
services and devices.  By the way, this ease the writing of
user-defined jobs without any need to manipulate the NixOS code to add
new features. (like disnix ?)

Is there some objection against this way of writing things ?

Out of subject: Is the "look back set" a good way to solve the problem
of the ghc compiler libraries? I guess it is because this will
resolved all requirements before trying to install the ghc compiler.

-- 
Nicolas Pierron
- If you are doing something twice then you should try to do it once.