Proposal: nixpkgs overlays for big things!

Hello, people! What do you think about to modularize Nixpkgs even more, using overlays in order to manage big projects as KDE, XFCE &c.

Hey, we even have some success with the now famous Emacs overlay!

As a proof-of-concept, I’ll try (again!) to restart my Trinity Desktop on NixOS pet project with that approach.

Ideas? Criticism? Anything, please drop some lines below!

It has been discussed that this could possibly be implemented with flakes.
Though we’d quickly lose our quality of being a mono-repo, not sure how release management would work for “released” nixpkgs flakes.

It could be just a “official flake” in that case. Being mono-repo is something more political than physical, in my opinion.

It could be just a “official flake” in that case. Being mono-repo is something more political than physical, in my opinion.

monorepo means having a unified commit ID across the entrire set of included things, though. This seems to be the reason for having NixOS and Nixpkgs as a single repo (just after migration they were separate repos under single org with identical commit access).

3 Likes

I agree that overlays or flakes might relieve some of our maintenance problems, but I think there are multiple axes to consider.

Some sets of packages are very divergent, KDE packages versus Erlang packages, for example. There are also platform definitions that can be potentially be applied to all package functions, but are divergent among themselves, Linux versus Darwin versus CloudABI. What I would like is an overlay mechanism for defining exotic platforms, or otherwise moving the majority of packages into overlays.

Wouldn’t be possible all these flakes “having a unified commit ID across the entire set of included things”?