[Nix-dev] Re: Boost libraries

[Nicolas Pierron]

On Thu, Apr 9, 2009 at 19:18, Isaac Dupree
<ml at isaac.cedarswampstudios.org> wrote:
> Lluís Batlle wrote:
>> Maybe there could be in pkgs:
>>
>> boost = if getConfig ["boost" "full"] true then boostFull else boostSmall;
>
> Such an imperative way to deal with configuration!
>
> If package configurations options were sufficiently declarative so that one could
> enumerate all of them, there could be constraint-solvers to determine a good
> solution given 1) desired packages/versions and possibly 2) what's already
> installed.  For example Haskell Cabal is working on constraint solving to
> choose what dependencies to install, although it's a difficult problem!  Even
> Debian apt-get has to make compromises sometimes.  But I think it's relatively
> non-critical for Nix because duplicate packages mostly just waste
> space/time/memory rather than being incorrect.  So there could even be
> different solver configurations, maybe optimizing for things like disk usage,
> compilation time, package provenness/stability, etc. (priorities could vary).
>
> Does that make sense?  Of course actually having a good constraint solver is a
> lot of work.  But what would Nix expressions have to look like, in order to
> even make this be a possible thing?

Nix packages can explicitly depends on packages with some activated
features, like:

{stdenv, subversion, ...}:

let
  subversionWithPerl = subversion.override {
    ...
  };
in

stdenv.mkDerivation {
  buildInput = [ subversionWithPerl ]
  ...
}

Such dependencies are explicitly adding a new derivation, based on the
previous one, which supports Perl.  I understand that the derivation
"subversionWithPerl" could be interpreted as a constraint but it is a
derivation, which implies a build process.  The difference between
constraints and derivation here reside in the evaluation process of
Nix.  Constraints are evaluated after collecting all of them and
return a solution or a list of solutions.  Lazy evaluation evaluate
each declaration when it is asked without looking at other
"instantiations".

I foresee some solution to this problem:

1) The Current System

Pro:
 - Each package has its own personalized dependencies which can be reproduce.

Con:
 - Waste of Hard drive / compilation time


2) Scoped Monadic Packages

Pros:
 - Allow multiple packages to share a subversion install containing
all features required.
 - Multiple scope can be created to handle incompatibilities.

Cons:
 - The subversion package (or another) could have a build failure due
to incompatible options.
 - Cannot reproduce an installation without installing the same set of
packages. (or activating each option manually)


3) Constraints on Packages dependencies

Pro:
 - Allow multiple packages to share a subversion install containing
all features required.

Cons:
 - Cannot reproduce an installation without installing the same set of
packages. (or activating each option manually)
 - Need to handle constraint programming in Nix. (or new extra
dependencies for Nix)


-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron
- If you are doing something twice then you should try to do it once.