On Sat, Dec 27, 2014 at 7:48 AM, Ertugrul Söylemez <ert...@gmx.de> wrote: > I think as a first step to get rid of systemd and gain a much more > sensible services model as well we should move away from NixOS modules > for services.
The module system is made in such a way that one can build on top of the work of the other without having any computer scientist knowledge. This is also the reason why I am pushing to abolish "functions" as option definitions. Most of the time if you want to use a function, you can express it as a set of input (option declaration) which are being processed to provide a lower level of abstraction given by another module (option definitions). The module system does not prevent us from doing anything, it provides a new way of formatting which makes things declarative and extensible. If a module does not serve what you expect, you can always write another module and use it instead of the previous one. Having multiple instances of a service is an issue with the module, not a limitation in the module system. > Being able to reason about the resulting system is very > important. Have you tried nixos-option ? > I would prefer and do propose an algebraic solution (view services as a > toolbox from which you can pick the services you want and compose them > together). A services configuration then might look like this: > > services = > bitlbee { port = 10000; stateDir = "/var/lib/bitlbee1"; } <> > bitlbee { port = 10001; stateDir = "/var/lib/bitlbee2"; } <> > nginx { httpConfig = "..."; } <> > postfix { postMasterAlias = "blah"; } First, unamed instance are not modular. This is why we are moving away from types.listOf and that the suggested alternative is a backward compatible version named types.loaOf (list or attribute set of). Second, I see 2 additional concepts and I do not think I would be able to explain these to my grand-mother, Can you? I think what you are trying to express can be done with the module system, maybe you can try to make a prototype using the module system and a new top-level "system-proto" option which is declaring submodule for every service that you want to declare. Maybe we can learn something from this experiment, in order to better design future services. In any cases, I do not think we want to switch to something without having a working prototype to experiment with. Do not take that personally, this was also the case with the module system [1]. [1] http://comments.gmane.org/gmane.linux.distributions.nixos/1187 -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev