[Nix-dev] Package collection problem.

[Nicolas Pierron]

On Thu, Feb 19, 2009 at 22:27, Marc Weber <marco-oweber at gmx.de> wrote:
>> What I am suggesting, is not introducing new names to indicates what
>> is included, but only to install what you are asking, not a predefined
>> set of libraries.
> That's fine with me..
>
> Just one use case (removing python interpreter) (A)
>  you install: python-2.5 libA libB libC
>
>  now you do nix-env -e python-2.5. What happens with libB and libC?
>  Should they be kept?

Yes, but the collection handler could handles theses cases by warning
the user or forcing the install of the python interpreter.

> using a wrapper everything is gone not leaving any rubbish as soon as
> you run nix-collect-garbage..

You can also provide some kind of aliases over a set of packages which
will do the same job in a simple way.

> Another use case (ugrading python forgetting about some libs) (B)
>  you install: python-2.5 libA-1.0 libB-1.0 libC-2.0
>
>  you told me that you don't want python-2.5-libA-1.0.
>  So what happens when you do
>  nix-env -e python; nix-env -i python-2.6?
>  Then you'll have python-2.6 but still python-2.5 libraries installed.
>  Luckily they just won't show up cause python does solve this for use
>  cause it using site-packages/2.5 or such.

That's the job of the collection handler to check for that either by
warning the user or ensuring that this could work.

>> My suggestion is to add some kinds of collection names to packages to
>> tell Nix that this package extends the python installation.  When Nix
>> encounter collection names, it will use specific environment builders
>> to build the final user environment.  This way, we would be able to
>> remove the stuff related to merging python libraries out of python
>> library builds and out of the python interpreter compilation.
>
> More details, please. How should such an environment builder look like ?
> I mean the environment builder must be able to cope with
> python-2.5 building libA libB
> and
> python-2.5 building libA' libB'
>  where libA' = libA and a patch
>        libB' = libB depending on libA

Each collection handler (environment builder) is a derivation which is
called with a subset of the list of packages installed by the user.
This list of packages is extracted from the whole list by filtering
collection names.  When this derivation is called it just build an
environment to ensure that this collection of packages is working.

So, let's take a dummy example:

{
  collectionHandler = {
    tex = {pkgs}: # list of packages labeled with the collection named "tex".
      stdenv.mkDerivation {
        ...
      };

    shellProfile = {pkgs}: # list of packages which provide a shell
initialisation.
      stdenv.mkDerivation {
        ...
      };
  };

  texliveCore = stdenv.mkDerivation {
    ...
    collections = [
      "tex"
    ];
  };

  texliveBeamer = stdenv.mkDerivation {
    ...
    collections = [
      "tex"
    ];
  };
}

In this case, the collection handler is just the aggregation function
that we currently have to call by hand after editing some nix
expressions.  My point is to be able to have a working tex
installation (or any other similar collection) after doing the
following commands:

$ nix-env -i texlive-core texlive-beamer
$ texi2dvi --pdf mysildes.tex

Collection handlers are transparent functions which are called to
merge packages which are part of the same collection.

> ...

Other questions are related to implementation details which can be
handled by this method because it does not remove any functionality.

On the other hand, this proposal is more general than Python and unify
the way to handle such problems by separating concerns and by removing
any need of hacky hand writing.

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