[Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[ikrek vagyunk]

dear fellow nixers,

i  followed this discussion and would like to propose (the already
proposed) way of sorting packages alphabetically and then add some
meta-tags. every package should be in a directory, just like today, with
default.nix and all other files needed for that exact package.

pros:
- would be mostly just automatically moving the current package set around
and adding meta-tags derived from the current directory structure
- all-packages.nix can invoke any package by doing:
  callPackage name {whatever options you want};
- if you add a new package, you instantly know where to put it
- if we would break the 1000 files github limit - or any other reasonable
directory-size limit - we easily can create subdirectories and move the
files accordingly (without any effort)
  /pkgs/a/ -> /pkgs/a and /pkgs/a/a_ (where underscore represents the most
used second character in /pkgs/a and all packages with that prefix could be
moved automatically - note: all-packages.nix wouldn't need to change)
- we would need some new meta-attributes (and they would be nice, i think -
querying for any kind of remote shell that is written in haskell or python
would be sth like: nix-query shell AND server AND (haskell OR python))
  attributes would be: meta.languages, meta.categories,...

cons:
- possible recompilation-issues whenever we move packages to subdirectories
- changes to callPackage/... may be necessary, if we don't want to manually
write the directories
- gnome/kde/haskell/... packages would be scattered around

even though i'm not as good with nix/nixos internals, i believe this is the
easiest way to manage things - correct me if i'm wrong (also add anything,
if you think i'm right, but the proposal is not clever enough ;))


anyway: keep up the good work ;)
regards, ikervagyok

p.s.: about users being capable of reading/writing nix-files: i convinced
three people to use nixos, none of them really use it though - so from my
position it seems like every real user is very capable - and we don't need
to worry much about non-nix-file-reading users...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160110/29d97445/attachment.html