On Tue, Feb 24, 2009 at 00:25, Ludovic Courtès <[email protected]> wrote: > Hi Nicolas, > > Nicolas Pierron > <[email protected]> writes: > >> The previous evaluation system had the following problems: >> 1/ Users have to learn all Nix features to patch NixOS and to put >> their hands into the code in order to add services or primary >> features. > > Hmm, the proposed approach makes a non-trivial use of lazy evaluation
Thanks ;) > for instance, while the current approach doesn't use any sophisticated > language feature. True, but on the other hand you don't have too know all evaluation details to write a configuration file. >> 2/ NixOS features are spread over multiple files without any clear links. > > Here I agree that what you propose is a significant improvement. > >> Main modifications made in this branch: >> - a few upstart-jobs conversion. >> - upstart-jobs/default.nix, etc/default.nix are configuration files. >> - extensible activation script. > > Can you elaborate on this? How does this relate to the main goal of the > branch? These modifications have been some kind of tests for me. Converting upstart-jobs has allow me to remark that lib.optional functions do not behave as we can expect in configuration files, therefore, I have introduced the mkIf function to factor conditions and to ensure that attribute which are not defined are not defined by the default else-value. The activation script modification was only to tackle some dependencies and check if we can easily write a script components in multiple files. The current version is working but there are still some writing issues to make this look nicer. >> - system parts can be build in multiple files. >> - xserver handles multiple .. at the same time: windowsManager >> (compiz, wmii, ...), desktopManager (kde, kde 4, gnome, ...) > > Again, how does it relate to what's discussed above? The system was mainly build into system/system.nix, this file had a lot of builder contained inside it. I have succeeded at moving them in other files (where they have some connections) and also sharing them with other files. Thus, now there is the attribute config.system.build which is an attribute set which contains all derivations which may be used by the system. This attribute should contains (in the future) all derivations used to generate the system environment which will be accessible under config.system.build.result . XServer modification was made after the enlightenment patch, the idea was to add a new feature to bring more people interest on this branch ;). At the same time, I have succeed at separating (yet another) hard coded list of window & desktop manager. I find these expressions pretty interesting because this ease the introduction of any new windows & desktop manager. This may be very helpful to get more and more user to NixOS. I have never really understood how this stuff were working before putting my hand in NixOS, but this separation of concerns is just amazing because everything becomes clear. >> Do you want me to push these modifications in the main line ? > > Did you somehow test those Upstart jobs that you didn't "upgrade" to the > new style to make sure they don't break? It would be unfortunate if the > first `nixos-rebuild' after the merge broke many Upstart jobs people > rely on. > > If we are confident that Upstart jobs won't break, then I'm OK with the > merge. I am not entirely confident with all upstart-jobs that I have converted because I am not using all of them. I have converted them because they seemed simple to convert, so if there is any error, this should not be a very hard to find it. > (BTW, merging this branch will blur revision history, which is > unpleasant. I would recommend against using git-svn(1) for merges, and > so does the man page, but I guess it's too late now.) All patches of the trunk have already been imported inside the branch, so merging in this case will just be a "svn mv" from the branch to the trunk. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - If you are doing something twice then you should try to do it once. _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
