flake: add overridable systems input

[MattSturgeon]

Users can specify which systems to use by having our systems input follow a different file or flake:

{
  inputs = {
    # Here we list systems in a local file
    inputs.systems.url = ./systems.nix;
    inputs.systems.flake = false;

    inputs.nixvim.url = "github:nix-community/nixvim";
    # Here we override the list of systems with only our own
    inputs.nixvim.inputs.systems.follows = "systems";

    # ...
  };

  outputs = inputs: {
    # ...
  };
}

# systems.nix
[
  "x86_64-linux"
]

Alternatively, instead of users listing systems in a local file, they
can use an external flake, e.g.:

• github:nix-systems/default
  • Exposes aarch64 and x86_64 for linux and darwin
• github:nix-systems/default-linux
  • Exposes aarch64 and x86_64 for linux
• github:nix-systems/default-darwin
  • Exposes aarch64 and x86_64 for darwin
• github:nix-systems/aarch64-darwin
• github:nix-systems/aarch64-linux
• github:nix-systems/x86_64-darwin
• github:nix-systems/x86_64-linux

See https://github.com/nix-systems/nix-systems

[GaetanLepage]

I always find it weird to rely on an extra repo for this.
But anyways, I think this is a good idea and gives extra flexibility to the users, so let's have it :)

[MattSturgeon]

I always find it weird to rely on an extra repo for this.

We don't have to. We could use systems.url = "path:./systems.nix" instead.

Using an external repo is just a minor convenience, in that we don't need our own list of systems.

Also, if we use nix 2.26+ to create a lockfile with a relative-path input, then that lockfile isn't backwards compatible with nix <2.26.

As for needing an extra input; that's a design limitation with flakes. The way flakes deal with "systems" is one of the major flaws pointed out by those who want to make breaking changes to the "experimental" flakes design. Let's not dig up that can of worms here! 🥫

[MattSturgeon]

I always find it weird to rely on an extra repo for this.

We don't have to. We could use systems.url = "path:./systems.nix" instead.

Without edolstra/flake-compat#71, we kinda do need to use an external input.

Using a relative path input will break flake-compat.

In my personal config, I worked around this by using edolstra/flake-compat#71 as my flake-compat input, but I'm guessing nixvim would prefer to wait for it to be reviewed and/or accepted upstream.

[mergify]

This pull request, with head sha 321279197268f900bfce4e1cd5cdd1fe8e96a385, has been successfully merged with fast-forward by Mergify.

This pull request will be automatically closed by GitHub.

As soon as GitHub detects that the sha 321279197268f900bfce4e1cd5cdd1fe8e96a385 is part of the main branch, it will mark this pull request as merged.

It is possible for this pull request to remain open if this detection does not happen, this usually happens when a force-push is done on this branch systems-input, this means GitHub will fail to detect the merge.

[GaetanLepage]

I always find it weird to rely on an extra repo for this.

We don't have to. We could use systems.url = "path:./systems.nix" instead.

Using an external repo is just a minor convenience, in that we don't need our own list of systems.

Also, if we use nix 2.26+ to create a lockfile with a relative-path input, then that lockfile isn't backwards compatible with nix <2.26.

As for needing an extra input; that's a design limitation with flakes. The way flakes deal with "systems" is one of the major flaws pointed out by those who want to make breaking changes to the "experimental" flakes design. Let's not dig up that can of worms here! 🥫

Thanks for the clarification @MattSturgeon :)