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

[Tony White]

2009/12/14 Nicolas Pierron <nicolas.b.pierron at gmail.com>:
> 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.
>

Hi Nicolas,
I think that you're wrong about the helper function or maybe you
didn't understand because I didn't explain it right?

Helper function daemon : I'm just sitting here in the background
listening for anything nix does.

User : I want to update automatically, so let's turn on this
(Non-existent in nix yet) Automatic update daemon that uses nix to
update nixos.

Automatic update daemon : Hmm, libtool is new, let's update it. Tell
nix to run the transaction.

nix : OK. I'm going to install libtool, I've just worked out all the
dependencies and the stuff I need to compile for you. Let's do it!

Helper function daemon : (Listening to nix say let's do it!) Nix stop.
Hmm, before you do, let's make sure that there is nothing happening to
effect conditions. Let's check the rules I have here.
Hmm, don't run nix if the battery is the primary power source. Check.
Are we running on batteries? Answer : yes!
Helper function daemon tells nix not to continue and provides an error code.
Helper function daemon then tells the automatic update daemon that it
wasn't allowed to do what it wanted, should stash the transaction that
failed and try to re-run it when an OK signal is received from the
helper function daemon.
Helper function daemon sends an OK signal to the automatic update
daemon when mains power has been connected.

I hope that's a good example of what I mean. Just simple calls to
follow rule sets.
You certainly wouldn't want nix to workout if the battery was running or not.
Nix would just need a conditional if statement to interact with the
helper function daemon. Otherwise nix can just do as it pleases, just
as normal.

It's a similar idea to packagekit but far, far greater because nix is
more powerful than deb, rpm, etc. And yes, it is a wild look into the
potential future, involving lots of work.

Stuff like: nano : comand not found. Would you like to install nano?
Would potentially be possible in a console (Install if not installed
but requested.)
Or wireless network detected, let's have the helper daemon ask the
questions to help configure it using configuration.nix.

Thanks,
Tony