Split up pkgs/development/libraries

[matthewbauer]

Issue description

pkgs/development/libraries has 1225 entries right now. It would be nice to split them up a little bit. At the least I want to get it below 1000 which is GitHub's max directory size.

• Move all SDL stuff to pkgs/development/libraries/SDL (~10)
• Move all QT stuff to pkgs/development/libraries/qt (~5)
• Move all GTK stuff to pkgs/development/libraries/gtk (~5)
• Move video stuff to pkgs/development/libraries/videos (~50)
• Add pkgs/development/libraries/data for libraries related to XML, JSON, (~50)
• Add pkgs/development/libraries/networking for libraries related to internet, networking, etc. (~50)
• Cleanup miscellaneous things that can be combined (taglib, vapoursynth, polkit, libnetfilter, gupnp, at-spi2, mesa, pcre, libdbusmenu, etc.) (~10)

Any objections to this? Pull requests towards this would be appreciated!

[bjornfor]

No objection, but I always thought the package hierarchy was somewhat annoying and would rather have it flat like pkgs/z/zlib, pkgs/g/git.

[jtojnar]

+1 for flat scheme like triton has. Many packages do not fall into a single category – for example, gupnp could belong into either videos, networking or gtk.

[matthewbauer]

but I always thought the package hierarchy was somewhat annoying and would rather have it flat like pkgs/z/zlib, pkgs/g/git

I used to agree with this but I have actually changed my mind. If done right the "nested-tree" style can be fairly useful. For instance it's done well with pkgs/shells and pkgs/applications/window-managers - you can clearly see the shells and window-managers that we have packaged. I think the key is to be very specific and try to get rid of the "catchall" directories like pkgs/applications/misc, pkgs/development/libraries, and pkgs/development/tools. The Nix expression language makes the name pretty much arbitrary but having a descriptive directory can be very useful for maintenance. In addition, I think it will fit nicely if we ever end up splitting up all-packages.nix into multiple files. (default.nix for each subtree?)

[bjornfor]

Right, the flat structure would have to use keywords of some sort (meta.keywords = [ "networking" "videos" "gtk" ] ?) in the expression files to maintain the grouping we have today with hierarchy. It's a trade-off.

[jtojnar]

I guess hierarchy kind of makes sense for applications, for example, you might want to test something in a multiple WMs. For libraries, however, it is less useful, since you generally know the library you want to use and there are not multiple implementations (maybe libc is an exception). Actually, it might be even kind of annoying – I was typing less p/d/l/colord and then pressing tab key like crazy but the library just was not where I would expect it.

[matthewbauer]

I was typing less p/d/l/colord and then pressing tab key like crazy but the library just was not where I would expect it.

Yeah I think this is definitely an issue. My solution is to just use EDITOR=echo nix edit -f. colord if you need the path.