introduce filterSystem

[blaggacao]

As an alternative to flattenTreeSystem, I propose filterSystem that directly acts on the output of current flattenTree and filters with a predicate that drops all packages that would trivially fail a nix flake check.

/cc @pacman99 @nrdxp

[Pacman99]

My solution but with nixpkgs lib:

 filterPackages = system: packages:
    let
      # Everything that nix flake check requires for the packages output
      filter = (n: v: with v; let platforms = meta.hydraPlatforms or meta.platforms or [ ]; in
      lib.isDerivation v && !meta.broken && builtins.elem system platforms);
    in
    lib.filterAttrs filter packages;

[nrdxp]

If it wouldn't be too much work to adapt @Pacman99's example to a version without a dependancy on nixpkgs, I think filtering would be a sane way to allow users to start experimenting with the newer packages output, without having to manually declare each system indivdually.

Obviously flattenTreeSystem got to a point where it was too complex to easily follow and debug, but perhaps just filtering would be more managable. If I ever find the time (which seems like a bigger and bigger if at this point), perhaps I could try my hand at a nixpkgsless implementaton.

I guess the question is still: what's the benefit of packages over legacyPackages i.e. why bother? I think flakes are trying to find a way to deal with the current ad hoc way of managing package groups that currently exists in nixpkgs. It will take an exceedingly curageous individual to actually attempt to start converting the monstrosity that is nixpkgs into properly segmented flake/subflakes and it's possible that the experimental implementaton will need to be modified further to actually achieve this.

All that is too say, if we don't try to solve this dilemma soon in a compelling way, then flakes may end up being a huge waste and users will just always rely on the crutch that is legacyPackages leaving flakes as little more than a convenience for dealing with fixed output derivations and their hashes.

Although, it is possible that package filtering would be better handled by some magic in nix itself as well. And this would only be the beginning of trying to structure an idiom for how packages are to be handled, but maybe it's a good one.

[zimbatm]

When I wrote flattenTree, I was under the impression that we should use packages and avoid legacyPackages due to the naming. Since then, my thinking has changed; nixpkgs is unlikely to become flat, as @nrdxp observed. I also think that having a hierarchy is useful for monorepos.

So for now, I would suggest ignoring the naming and use legacyPackages instead. From what I know about flakes, I really hope that this is not the final design as there are some other deeper issues with it. For example, if each flake creates an instance of nixpkgs, and evaluating nixpkgs takes 400MB of RAM, it's not going to scale.

[blaggacao]

Implemented by #28