Add a default value for systems

[Atry]

This PR is based on #146

[srid]

I think it is better to explicitly do this in the user flake, than have flake-parts do it automagically for you, especially when we are hoping to create an architectural solution to this problem in flakes itself (thus obviating nix-systems).

[roberth]

Setting a default list of inputs is not a responsibility of the flake-parts core, and yes, Nix itself should make setting a list of systems optional. If anything should set a default, it'd be nixpkgs itself.

Furthermore, flake-parts modules in general should not recurse through the inputs, let alone the core modules. I'll add that to the best practices page.

[edrex]

How about adding the two lines for the systems flake approach to the flake-parts template?

[shanesveller]

As a regular old flakes end user, I see pretty low value in taking on still-another third-party flake input to be indirect about this. I would be deleting those two lines every single time I ran the template.

As a flake module publisher instead, I don't care about folks using something I shared on a platform I didn't design it for, I'm not going to take active moves to prevent that, but the list of systems I wrote in the flake are the finite set of platforms I support and design for. Anything else is caveat emptor and it feels strange to me to want to let end users manipulate that by something far-removed from what I developed, tested, and published. I can see how it's helpful to limit a consuming flake to worry about a subset of the library flake's supported systems, I suppose.

[edrex]

@shanesveller the degree to which you care about systems will depend on how tightly coupled the primary outputs of the flake are on systems. Times when you will really care:

1. you're doing platform specific stuff, eg ASM, platform specific blobs, targetting ABIs
2. you depend on packages which don't build on certain platforms (ie, stuff that doesn't build for ARM)

Most of my flakes are integration glue written in high-level languages, so (1) doesn't apply, although I occasionally run into (2).

The problem with the current approach is that there's no way to override it downstream without forking. Whether or not you as a particular author care, there are people in the ecosystem, like me, who need the ability to specify additional systems downstream in order to do their work. Putting systems in a (very simple) flake input utilizes the architecturally-supported override mechanism of inputs to make systems overridable. :shrug: