[Nix-dev] Re: Merging fix-style branch into the trunk ?

[Nicolas Pierron]

On Tue, Feb 24, 2009 at 00:25, Ludovic Courtès <ludo at gnu.org> wrote:
> Hi Nicolas,
>
> Nicolas Pierron
> <nicolas.b.pierron at gmail.com> 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.