Ertugrul Söylemez <ert...@gmx.de> skribis: > 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"; } > > The big difference is that now services are first class values and form > a monoid under composition, which brings a number of advantages:
FWIW, Guix uses an approach along these lines: the ‘bitlbee-service’ function, for instance, returns a ‘service’ object as a monadic value (see <http://www.gnu.org/software/guix/manual/guix.html#Defining-Services> for details.) Unlike in NixOS, the service implementation doesn’t have access to the rest of the system configuration, which I think is a good thing, as you note. What’s unsatisfying (and thus subject to change) is that ‘operating-system’ objects (which are pure declarations) end up with monadic values in their ‘services’ field. That makes it inconvenient to, say, filter items from that list, or to tweak their configuration, because one first needs to bind them. That said, it’s probably not a problem for Nix, because every Nix function is really a function in what we call the “store monad”. In your example, what would ‘bitlbee’, ‘nginx’ etc. return exactly? An attribute set describing the service? Anyway, I’m interested in following this discussion. Thanks, Ludo’. _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev