[Nix-dev] [Nix] Feature request for NixOS introspection.

[Nicolas Pierron]

On Mon, Dec 6, 2010 at 23:04, Eelco Dolstra <e.dolstra at tudelft.nl> wrote:
> Hi,
>
> On 12/06/2010 07:52 PM, Nicolas Pierron wrote:
>
>> I am trying to bring up a tool to analyze NixOS option and
>> automatically detect where options are used.  I already made an
>> expression which produce a pdf file
>> (nixos/maintainers/option-usage.nix).
>
> How does it work?  It sounds like a fairly tricky problem (without support in
> the evaluator).

It first evaluate the config (1), and inject the config where one
option value (2) has been replaced by an error and re-evaluate the new
config (3) (extraArgs is used to replace the config attribute).
Comparing errors between the config (1) and the config (3) determines
the options impacted by the modification of (2).

This "almost" correspond to one step of a fix-point on the whole configuration.

>> I updated it considering the
>> memory consumption in order to benefit from the garbage collector of
>> nix expressions.
>>
>> Unfortunately, the tryEval primitive has changed since.
>
> The semantics of tryEval did change once, but I think that was quite a long time
> ago...

indeed, this was a long time ago, and I also mention this issue.  And
If I remember well, you answer me that this could leave the
interpreter in a bad state.

>> When I
>> started this script it was catching everything, but now it only catch
>> assertions errors.  Sadly, evaluating strictly NixOS configurations
>> can lead to unexpected errors, such as throw, bad types, ...
>
> Why do you need to evaluate it strictly?

Because I need to raise the error by forcing the usage of the inserted failure.

> That seems dangerous (even if you
> could catch all exceptions) due to the risk of infinite recursion.

This could be a risk, how does toXML handles infinite recursions?

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/