[Nix-dev] Resolution context of `require' paths

[Nicolas Pierron]

Hi,

I am working to implement the following proposal, but I have a syntax issue ...

On Tue, Jun 30, 2009 at 11:28, Eelco Dolstra<e.dolstra at tudelft.nl> wrote:
>  {config, pkgs, modules, ...}:
>
>  {
>     require = [modules.intel4965agn];
>  }

Adding modules as argument is simple and I've made a patch for it.


>  modules =
>    { intel4965agn = ./hardware/network/intel-4965agn.nix;
>      sshd = ./services/networking/sshd.nix;
>      ...
>    };
>
>  modules =
>    { intel4965agn = ./hardware/network/intel.nix;
>      intel3965abg = ./hardware/network/intel.nix;
>      ...
>    };

The issue comes from here.  Such file implies that you will have to
maintain a file which contains every modules in addition to the file
module-list.nix which was generated.  The reason that the generated
method have been forgotten is that Eelco does not want to create
multiple module directories (which I see as a lack of modularity in
our writing).  The module-list.nix file was generated by copying the
filename into a list.  The current proposal implies that you can have
multiple identifiers for one filename which I consider to be difficult
to maintain because you won't catch the error if the file is not used.
 Moreover such file will be similar to all-packages.nix because it
will become a catch-all and the center of all modifications.

The syntax issue comes from the point that I want to generate such
file.  I want to generate a module-index.nix file at the root of the
module directory which is based on what is found inside each module.
To implement such thing I though as an ugly comment-syntax:

--- sshd.nix
#= sshd; list.default, list.minimal
{pkgs, config, ...}: ...


--- intel.nix
#= intel4965agn, intel3965abg; list.firmwares.intel
{pkgs, config, ...}: ...

IMO, this syntax is too far from the Nix syntax to be considered as a
good solution.  Eelco Dolstra suggested the following syntax a few
months ago.

On Tue, May 26, 2009 at 13:42, Eelco Dolstra<e.dolstra at tudelft.nl> wrote:
>  {config, pkgs, ...}:
>
>  {
>    # Dependencies (just a list of filenames).
>    require =
>      [ ./filename.nix
>      ];
>
>    # Option declarations.
>    options = {
>      foo.bar.enable = mkOption { ... };
>    };
>
>    # Option definitions.
>    config = {
>      xyzzy.fnord = 123;
>    };
>
>    # And maybe a module could have some other attributes, like...
>    name = "bla";
>    description = "...";
>  }

This syntax has the advantage to be unambiguous about the require
attribute, adding meta field to modules and to separate the interface
(declarations) from the implementation (definitions) in a clear way.
This syntax may help to introduce a new meta field which contains the
following content:

--- in sshd.nix
names = [ module.sshd ];
groups = [ module.list.default module.list.minimal ];

names = {
  sshd = null;

};

--- in intel.nix
names = [ module.intel4965agn module.intel3965abg ];
groups = [ module.list.firmwares.intel ];

These meta fields will all contains the current file path.  Groups are
lists of modules and names are just the names to target one precise
module.  With this writing we can as well generate multiple list of
modules list

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron
Donald Knuth - I can't go to a restaurant because I keep looking at
the fonts on the menu.