[RFC] set default for systems and use a better interface for exposing packages

[Mic92]

Most folks I have spoken too agree that having the user specifying systems is not great ux.
It does not seem that the nix core developer are focused on fixing it any time soon.

So how about the following approach. Nixpkgs already has a great interface for a package to communicate what platforms in can be build on called meta.platforms. So why not having meta checks on attributes to filter out packages that are not supported in flake-parts? flake-parts already has enough of knowledge of the flake schema do this filtering.

[Mic92]

I digged a bit deeper and tried to do the filtering on the module level:

{
      perSystem = { config, self', inputs', pkgs, system, ... }: let
        exposeSupported = lib.filterAttrs (_: pkg: lib.meta.availableOn pkgs.stdenv.hostPlatform pkg);
      in {
        packages = exposeSupported {
          ssh-to-age = (pkgs.callPackage ./default.nix {});
          default = config.packages.ssh-to-age;
        };
      };
}

However there the problem is that filtered module options would become unavailable if other places try to use config.packages.<filteredPackage>, so I think this filtering would need to be done after evaluating all exposed packages.

[Mic92]

Another issue is that this only check if the package itself advertises certain platforms.
Checking recursively for meta.platforms is a bit tricky to implement. This is roughly what hydra does for nixpkgs: https://github.com/NixOS/nixpkgs/blob/master/maintainers/scripts/eval-release.nix However this might become an new usability issue because suddenly package outputs disappear when a package's dependency no longer advertises a certain platform... So maybe only taking meta.platforms into account might be a better tradeoff and less expensive to check

[roberth]

It does not seem that the nix core developer are focused on fixing it any time soon.

This Nix Maintainer Team is working through a large backlog. We are considering the problem, and while I think it's important, we can't prioritize this one thing. The team members do perform some implementation work, but the main role of the team (as a responsibility rather than a group of people) is to set a direction and guide contributions.

filter out packages

As you also mention later, filtering is a problem for expressions that consumer these attributes.
Specifically, it makes code that's strict in a single attribute value strict in all the other attribute value, instead of just the other attribute names; similar to #59.
Unexpected strictness is bad for performance and reliability, as errors will propagate to unexpected places. In the worst instances, it turns benign dependencies into infinite recursions.

Like #59, the filtering should be applied as late as possible. Flake-parts could support this as late as the end of mkFlake (ie after, not in the module fixpoint). However, that's still before these attributes are consumed by other flakes, so an even better place for this is in the CLI.

Checking recursively for meta.platforms is a bit tricky to implement.

Nixpkgs could check it before returning the output attributes, as part of mkDerivation.

Sounds like

• [RFC 0127] Nixpkgs "problem" infrastructure NixOS/rfcs#127

[srid]

See also: #28

[Mic92]

This Nix Maintainer Team is working through a large backlog. We are considering the problem, and while I think it's important, we can't prioritize this one thing. The team members do perform some implementation work, but the main role of the team (as a responsibility rather than a group of people) is to set a direction and guide contributions.

I am sorry if this came across harsh. I feel personally that the nix package manager is one of the projects that makes it the hardest to get changes accepted and I think I contributed to a fair bit of projects. I feel so frustrated about that I do not consider any patch that is more than 4 lines because it won't get reviewed anyway. Instead I create projects that put hacky wrapper around nix what could be done in a lot cleaner way in nix itself. I have seen many very good contributions that have been tested by other non-committers that get ignored. If the backlog gets too large is too big, would it be not time to go through the list of contributors and add more people as reviewer (even if they do not have the merge bit)? I also do not see any https://github.com/search?q=repo%3ANixOS%2Fnix+roadmap&type=code in the repository where people could pick up tasks to take of load from the core contributors.

[roberth]

Thank you for giving feedback!

If the backlog gets too large is too big, would it be not time to go through the list of contributors and add more people as reviewer

That's part of why I'm on the team now, to help out. We have to split our time between reviewing contributions, design discussions to guide contributions, fixing bugs, and some tech debt.

roadmap

You're right, we should probably put more emphasis on tagging and elaborating feature issues that can be worked on by others.

I am sorry if this came across harsh.

I know how it is and I don't take it personally. That's very easy for now, because I haven't been on the team for a long time yet, but please stay honest; we need that. If we fail to deliver this year, feel free to point that out.

[roberth]

Regarding systems, I wrote this one earlier today and I'll try to greenlight it soon

• Extend the flake / cli interface with a function for system-specific attributes NixOS/nix#7709