[Nix-dev] Separating free and non-free packages, again

[Tony White]

2009/11/21 Marc Weber <marco-oweber at gmx.de>:
> Hi Tony,
>
> you missed a small detail.
>
> Let's have a look at a complete example how it could look like:
>
> === free/all-packages.nix: ====
>
>  setup@{
>      system ? builtins.currentSystem
>    , stdenvType ? system
>    , bootStdenv ? null
>    , noSysDirs ? true
>    , gccWithCC ? true
>    , gccWithProfiling ? true
>    ,  config ? null
>  }:
>
>  let overlay = name: if builtins.pathExists "../${name}" then
>        (import ../python-packgaes/all-packages.nix) setup;
>      else {};
>
>      requireOverlayPackage = path: overlays:
>        let r =  attrByPath list overlays null;
>        if r == null then throw "missing packages ${path}, get the the missing overlay, please!"
>        else r;
>  in
>
>  # simplified:
>  let pkgs = {
>
>    overlays = {
>      nonFree = overlay "non-free";
>      ovorlayPythonPackages = overlay "python";
>      ovorlayHaskellPackgaes = overlay "haskell";
>      ovorlayMyPrivatePackages = overlay "mine";
>      // you can add more using packageOverrides or we can find a
>      // different way!
>    };
>
>    /* the other overlays of course have this to refer to the free packages:
>    free = (import ../free/all-packages.nix) setup;
>    */
>
>    audacity = stdenv.mkDerivation {
>      inherit audioLib gcc ...;
>      # if the non-free overlay is there pass the package else pass null
>      nonFreePackage = attrByPath ["nonFree" "nonFreePackage"] overlays null;
>      nonFreePackage = requireOverlayPackage ["nonFree" "nonFreePackage"] overlays;
>    };
>
>  }; in pkgs;
>
> == end ==
>
> And of course packages can referer to packages defined in other overlays
> multiple times.
>
> Of course this is only a draft and not a final implementation.
>
> Tony, do you get/like the idea now?
> Do you think this really adds that much overhead?
>
> The benefits are:
> You can remove the non-free repository and be done.
> You won't get it back by svn update.
> You can add different experimental overlays for things which change to
> fast so that they should not be included into the main repo (yet).
>
> drawbacks:
> You have to synchronize multiple repositories. But I think we can live
> with that.
>
> This solution will scale. Each small company can add its own overlay
> with internal packages etc.
>
> Maybe we can even look at nixos being an overlay only then.
>
> Thoughts?
> Marc Weber
>

Hi Marc,
I like your overlay idea. It appears to be a very interesting and
potentially very useful concept for doing a good amount of the stuff I
want to do. Potentially even all of it.
Synchronising multiple repositories is fine. I actually prefer that.
It keeps things separate.
Using a script to pull world is trivial.

I can see how it would also make expression writing easier. No need to
use a version tracker to revert commits to an expression, if editing
breaks it. Just don't push the overlay repo instead and then come back
and edit it once you know how to make it work.
It would also create the possibility to half finish editing an
important system expression (Like qt4) And then just come back to it
when you have time to make it work properly, without negatively
affecting a repo push. No need to first stash the relevant commits
before a repo synchronization.

A very nice concept IMO. At face value; it certainly would be
something that I am interested in if it were to be implemented.

What does everyone think about Marc's override overlay draft proposal?
Is it viable?

Thanks,
Tony