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

Nicolas Pierron nicolas.b.pierron at gmail.com
Sun Jul 5 16:23:30 CEST 2009


On Sun, Jul 5, 2009 at 16:22, Nicolas
Pierron<nicolas.b.pierron at gmail.com> wrote:
> 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 ];

or

names = {
  sshd = null;
  list.default = [ null ];
  list.minimal = [ 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.
>



-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron
Richard Feynman - I think I can safely say that nobody understands
quantum mechanics.



More information about the nix-dev mailing list