2009/11/21 Marc Weber <[email protected]>: > 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: ==== > > se...@{ > 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 _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
