[Nix-dev] Package collection problem.

Nicolas Pierron nicolas.b.pierron at gmail.com
Thu Feb 19 00:27:19 CET 2009


Hi Nixers,

I have remarked while installing texlive that I need a function to
aggregate all tex packages that I may use in order to have a set of
working tools.  IMO, such things should not appear to the user as the
user may only want to install texlive-core and texlive-beamer and not
a wrapper.

The problem exists in other form in other set of packages:
- ghc: You want to install libraries, and not a compiler with a list
of supported libraries.
- ruby or python: You want to provide mutable install instead of
hacking with extra environment variables.
- All packages which need a well initialized shell: You want to
provide a shell script which initialize the user environment.

All these packages suffer form the same symptoms:
- hard to maintain.
- hacked install process.
- need user documentation to be installed.
- need user hacks to make them works.

Hopefully, the texlive aggregation function provide a bit of the
solution.  The question is, what do you want to do with packages which
are part of an identical family?

In this mail, I am suggesting that we should add something to declare
""aggregation"" families inside each packages.

pkgs.stdenv.mkDerivation {
  ...

  families = {
    inherit (pkgs.families) tex;
  };
}

Families may be used to provide "pre" & "post" action for building the
environment.

An issue arise from this model, which is how could we link between
package families/collection and individual packages.  One think to
remember is that users don't want to explicit this.  A possible
solution is to use families properties to aggregate all derivations in
order to build either the system environment of the user environment.

This may also help us to factor functions like aggreagateModules,
buildEnv, texLiveAggregationFun, ... into one buildEnv function which
use families to either aggregate modules, texlive packages or haskell
compiler libraries, ...  This will avoid any weird installation
process which implies that the user is either able to write a Nix
expression or shell script.

Do you have any complains about such system ? and any idea about its
implementation ?

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



More information about the nix-dev mailing list