fix: remove flake-parts nixpkgs-lib follows nixpkgs

[Lymah123]

flake-parts has its own nixpkgs-lib input from which it inherits lib. This repo was overriding that with inputs.nixpkgs-lib.follows = "nixpkgs", routing it through statix's own nixpkgs. Since nixpkgs has flake = false, it's a bare source tree with no flake outputs, so flake-parts fails to find nixpkgs-lib.lib and evaluation errors immediately.

Removing the follows lets flake-parts use its own pinned nixpkgs-lib, which is a proper flake. This fixes the nixpkgs bump failure reported in #2677

[Lymah123]

@mightyiam, the PR is ready for review.

[mightyiam]

Thank you for looking into this, @Lymah123. The solution in this PR is indeed a valid one, but I'd like to clarify the root cause, verbosely:

The problem is a discrepency between the flake.nix and the flake.lock. The flake.nix specifies nixpkgs with flake=false, while the flake.lock does not, defaulting to flake=true.

This can easily occur because, unlike other changes to inputs, changes to the flake attribute are not picked up and applied to the flake.lock by various flake commands. It is reported as NixOS/nix#8511.

Apparently, flake-parts needs a nixpkgs input that is a flake. What occurs in PRs that merely bump Nixpkgs, is that they trigger the propagation of flake=false into the flake.lock, at which point nixpkgs ends up not being a flake, resulting in flake-parts failing to evaluate.

Now, nixpkgs is an input that does not have any of its own flake inputs, so we don't mind keeping it flake=true. That, would be a slightly more efficient solution, because then we would not end up with an additional input in the lockfile.

[Lymah123]

Thank you for looking into this, @Lymah123. The solution in this PR is indeed a valid one, but I'd like to clarify the root cause, verbosely:

The problem is a discrepency between the flake.nix and the flake.lock. The flake.nix specifies nixpkgs with flake=false, while the flake.lock does not, defaulting to flake=true.

This can easily occur because, unlike other changes to inputs, changes to the flake attribute are not picked up and applied to the flake.lock by various flake commands. It is reported as NixOS/nix#8511.

Apparently, flake-parts needs a nixpkgs input that is a flake. What occurs in PRs that merely bump Nixpkgs, is that they trigger the propagation of flake=false into the flake.lock, at which point nixpkgs ends up not being a flake, resulting in flake-parts failing to evaluate.

Now, nixpkgs is an input that does not have any of its own flake inputs, so we don't mind keeping it flake=true. That, would be a slightly more efficient solution, because then we would not end up with an additional input in the lockfile.

Thank you for the detailed explanation. So the inconsistency between flake.nix (flake = false) and flake.lock (still flake = true) is the actual root cause, with nixpkgs bumps being the trigger that forces the lockfile to catch up and propagate flake = false, breaking flake-parts at that point. Will update the PR to remove flake = false from nixpkgs instead, keeping the follows in place to avoid the extra lockfile entry.

[mightyiam]

I think that the conventional commits type fix is for fixes that are user facing. So I squashed with chore.