This is really interesting. Right now you can't really compose nix expressions from several different sources. There are ways of doing it, but they all involve one hack or another that limits the usefulness of the result. This is why nixpkgs is a huge monolithic repository.
Flakes would allow package definitions from different sources play well with each other. This means a bunch of things:
1) Nixpkgs could be broken up into several package sets for better scalability. Eg,
haskelPackages and pythonPackages could be broken out into separate repositories.
2) Package authors could provide package definitions along with the source.
3) Companies could have a flake for internal packages without having to patch or
overlay nixpkgs.
4) Alternatives to nixpkgs can get started without having to supply all the packages
that a user might need.
5) You could even create libraries of nix functions that supply no packages at all,
but get used by other flakes to define packages. For example, the machinery for
composing a python environment.
> 1) Nixpkgs could be broken up into several package sets for better scalability. Eg, haskelPackages and pythonPackages could be broken out into separate repositories.
While this could happen, it's exactly what I hope won't happen, because in my opinion the idea that haskell or python packages are fundamentally different and can live in their own world is a fallacy. I spend quite a bit of my time fixing python packages on nixpkgs master and the number of times the fix actually involves making a tweak to a non-python library means I would forever have to be playing games synchronizing repositories. Also, gone would be the ability to make atomic changes across these boundaries.
Nixpkgs as a monorepo is great if all you want to do is install FOSS packages on your NixOS linux box. That's probably the biggest use case for nixpkgs, so it's important, but it's not the only use case.
If pythonPackages were broken out into a separate repository (which I'm not advocating, it was just an example), you'd fix a python package by importing the upstream library from the nixpkgs flake, tweaking it locally and then using the local version as buildInput to the python package. Sometimes it would make sense to submit the fix upstream, and sometimes not.
At the same time, we really have run into scaling issues—automatically importing all of Stackage into nixpkgs was killing us for a while there.
Regardless of whether nixpkgs remains a monorepo or not, I think 2) is actually the most exciting thing about the flakes proposal. Package authors being unable to supply nix packaging within the package repository is a big impediment to the adoption of nix.
Me too. I think (hope) that the NixOS community won't end up doing all the work it would take to break up the existing monorepo; instead they'll just add a few small additional repos.
Flakes would allow package definitions from different sources play well with each other. This means a bunch of things:
1) Nixpkgs could be broken up into several package sets for better scalability. Eg, haskelPackages and pythonPackages could be broken out into separate repositories.
2) Package authors could provide package definitions along with the source.
3) Companies could have a flake for internal packages without having to patch or overlay nixpkgs.
4) Alternatives to nixpkgs can get started without having to supply all the packages that a user might need.
5) You could even create libraries of nix functions that supply no packages at all, but get used by other flakes to define packages. For example, the machinery for composing a python environment.