[Nix-dev] Howto resolving dependencies automatically but much faster ?

[Nicolas Pierron]

Hi,

On Mon, Dec 14, 2009 at 07:01, Tony White <tonywhite100 at googlemail.com> wrote:
> 2009/12/14 Marc Weber <marco-oweber at gmx.de>:
>> Adding haskell specific code to nix itself is not the way to go, is it?

Nix has features which makes it different from other languages and
thus more suitable for some problems and not for others.  So we should
not use Nix for everything.

>> So how do you think about extending nix so that you can use arbitrary
>> languages to implement builtin functions?
>>
>> So do you think we can extend nix so that it loads additional plugins
>> (.so files) which provide these features?

This should be easy to do implement a loading of dynamic libraries,
but one of the issue is related to the compilation of these dynamic
libraries.  Currently Nixpkgs and NixOS are interpreted and you can
evaluate the result without any compilation ( nix-instantiate
--eval-only ).  If you want to provide libraries, thus we have to
compiled them locally to before any instantiation.  I would prefer to
have an additional keyword similar to "import" where a Nix expression
is injected inside the evaluation process.

Thus you can have something like:

let
  myBuiltins = import ./foo.so "toplevel" ;
in
  myBuiltins.bar 42

in this example, the evaluation of myBuiltins may return something like:

{
  bar = import ./foo.so "bar";
  baz = import ./foo.so "baz";
}

The idea is that the Nix interpreter will dynamically load a function
from the library named ./foo.so.  This function will return an
evaluated term (under normal form) which can add references to his own
functions.

The term (import ./foo.so) is a function which return a term in normal
form when it is called with a function name.  This can be based on the
filename extension and can tweaked to support other kind of extensions
like (import ./foo.sh).


>> Or how would you try to enhance speed for specific tasks ?

You should not blame Nix for not being inefficient for something which
is not is goal.  The problem you encounter was a memory issue.  One
solution could be to add scoped caches where the cache is dropped when
an operation is complete.


> Maybe nix would benefit from a helper framework to tell other things
> what it's doing or to ask it to do things? Stuff like : Don't start
> this silly two hour build transaction, if I'm running my machine on
> batteries, kind of thing. Or run nix with lower priority if I switch
> to watching a game or playing a video, etc.
> So like, calculate this really hard cabal-install transaction, then
> create the expression file for it and tell nix to package it sort of
> thing?

Unfortunately not.  If you want to extend Nix, you still have to keep
in mind the basics principles of Nix.  Your Nix extension have to be
pure.  You don't want to have a result which your battery status.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
Donald Knuth - I can't go to a restaurant because I keep looking at
the fonts on the menu.