[Nix-dev] Question about "package sets"

[Marc Weber]

Excerpts from Karn Kallio's message of Mon Aug 23 16:26:26 +0200 2010:
> Nixpkgs has several "package sets" such as emacsPackages, haskellPackages, 
> pythonPackages that generally group together expressions depending on a 
> particular interpreter or compiler.  Sometimes they use recurseIntoAttrs  ( 
> python, perl ) and sometimes not ( emacs, haskell ) .  There is no package set 
> like cPackages or gccPackages that groups expressions depending on a C 
> compiler nor a javaPackages.
> 
> Is there a policy or convention as to when to form package sets and if so 
> whether or not to use recurseIntoAttrs?
> 

Hi Karn,

I introduced some of them (without caring much about convention):

one reason is:
users being interested in one package may be interested in related
packages. Examples:

- gitAndTools
- gimpPulgins

But that fits my way of browsing packages: I always open
all-packages.nix and use Vim to dive into the imports.

About haskell, ruby, perl, python  packages:
Its obvious that you don't want to clutter the global all-packages
namespace with it. Eg the C library and the "perl,ruby, .." bindings
maybe named the same way. So there are various reasons why it makes
sense to group them.

Some have only have a small user base: Eg misc.
So it makes sense to move them into a corner.

You should know that there are two alternatives this style:

A) pass dependency explicitely:
python26Packages =  pythonPackagesWithInterpreter python2.6 

B) use deepOverride

  - deepOverride (maybe deprecated). Eelco Dolstra said he disliked it.
  so we proposed a patch - which is still waiting for an additional
  reply.
  So this may or may not be considered deprecated

C) use pass a different pkgs attr set to a derivation overriding a
   particular dependency.

  Example:
  http://article.gmane.org/gmane.linux.distributions.nixos/4475

  Note: this patch is still waiting for a final ok (for weeks now)


B, C are kind of hacks allowing to override packages in a dependency
chain. Eg they have been used for webkit and gimp which required a newer
than the default glib - which affected quite a lot of packages.

OT: There is a second implementation of haskellPackages. It gets
packages directly from hackage. See hack-nix. Its based on the same ghc
derivations.

Marc Weber