[Nix-dev] Re: NixOS: New scheme

[Marc Weber]

On Tue, Nov 18, 2008 at 10:49:48PM +0100, Ludovic Courtès wrote:
> Hi,
> 
> Marc Weber <marco-oweber at gmx.de> writes:
> 
> >> too coarse-grain, and it breaks the principle of least authority.  I
> >
> > In general this is good.
> 
> No it's not.  :-)
> 
> > I really fail to see what difference it makes as
> > - the jobs are run as root anyway
> > - the jobs can run rm -fr / as root as well..
> 
> This is not what I had in mind.  I was referring to PoLA in the context
> of our "program" code, i.e., the Nix code in the NixOS repository.
> 
> If we were to make an analogy with a language like C, passing `pkgs'
> and `config' to every function amounts to passing arguments using global
> variables.
> 
> That is, instead of
> 
>   int
>   do_things (pkg_t foo, pkg_t bar)
>   {
>     ...
>   }
> 
> you would write:
> 
>   struct
>   {
>     pkg_t foo; pkg_t bar; pkg_t baz; pkg_t chbouib; ...
>   } pkgs;
> 
>   int
>   do_things (void)
>   {
>     /* Use `pkgs.foo', etc.  */
>     ...
>   }
> 
> As a functional programmer, you will surely agree that this is bad
> programming style.  ;-)
Let's don't mix things. Each programming language has its use cases..
And comparing a passed pkgs with a C struct ? Don't think this is a good
comparison. The same for linux kernel: shared data vs individual
components which may die without taking the system down etc..

I'd like to tell you about my experience:

There are at least 3 major ways:
a) the with style:

    pkgs: with pkgs {
      buildInputs = [ foo bar ];
    }
   This is nice for _small_ derivations where you can have a look at each
   code line on the screen.

b) The pkgs passing everything global env style:
  
  pkgs: pkgs.stdenv.mkDerivation {
    buildInputs = [ pkgs.foo pkgs.bar ];
  }

  Here it *is* easy to see what is used. Just search for "pkgs.".
  That what I'd advocate for all sub environments such as
  a) collection of ghc libraries
  b) collection of python libraries
  c) collection of perl libraries
  
  Because you need pkgs.db4 pkgs.python pkgs.mysql pkgs.... whatnot.
  (All foreign bindings ranging from curl up to curses)
  If you don't call it pkgs but only p. the overhead writing the p. is
  minimal.

c) The one arg fore each dep style:
  { foo ? null, bar ? null, ... } : {
  }
  Damn, how often did I run nix-env getting a xy is not defined due to 
  adding xy to all-packgase but not to that list? I'd say let's remove
  that from all small derivations. It is bloat only in that use cases. 
  And it causes conflicts when merging. I don't see any advantage.
  It's only useful if the function decclaration serves as documentation
  or when the function defines an important interface (such as the top
  level function in all-packages itself. I'd never replace that with
  args: ... )

And seeing a statement such as its hard to see which dependencies a job
has? Try nix-store -q --tree $storepath. That's why we are using nix.

About jobs: I'd prefer the b) style maybe just using p. instead of pkgs.
Why? Overall nix is also about getting a job done/ implemented. And this
reduces bloat thus is a good thing (IMHO).. I agree that with pkgs;
should not be used then.

Thanks for reading my 2 cents.

Marc Weber