[Nix-dev] On nixpkgs and reasonable code size

zimbatm zimbatm at zimbatm.com
Sun Feb 21 15:17:16 CET 2016


Hi list,

tl,td; I think that we should split nixpkgs/pkgs in two

nixpkgs is getting pretty huge. There is so much surface, I don't think
that a single person can keep up with the pace of change and still manage
to do other things in the same day. Luckily we do have ~5 super-human
people taking care of triaging issues and merging PRs but there is a limit
of how much code each person can maintain. We can stretch that limit a bit
but then the quality will probably go down. At the same time we also would
like to be inclusive and not reject new packages.

We have a list of officially-supported packages (the ones built by hydra).
As a user, when installing a package it's not always clear if the package
is supported or not.
As a nixpkgs maintainer it is also unclear what priority should be given to
each package as the of officially-supported packages is not first class.
For example gettext is used everywhere but not directly part of release.nix

I am a bit reluctant on proposing an implementation details (bikeshed
ahead) but I think that at least we should split pkgs/ in two. pkgs/ would
retain the officially-supported packages and release.nix would essentially
be == all-packages.nix. And then have a community/ folder that contains all
the other packages. Both of them would stay in nixpkgs so that we can still
introduce atomic changes across the board.
The rest is a bit unclear to me but at least it would be easy to look it up
in the repo by hand for now.

I am happy to give it a go but since it's quite a big change I thought I
might discuss it here first.

Cheers,
z
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160221/9b29c9f0/attachment.html 


More information about the nix-dev mailing list