The concept of having a "minimum supported Nix version" doesn't work
anymore today, for the following reasons:
- With multiple forks / implementations of Nix available, their feature
sets and versions will differ. We'd need *multiple* minimum versions,
one for each implementation.
- Lix does not expose its real version. It only reports "2.18.3-lix",
even though its real version is in the 2.90+ range.
- A minimum version has the expectation that it could be *raised* in the
future. That's not possible with Lix, because Lix will always and
forever report the above version.
- A minimum version has the expectation that *all* versions bigger than
the minimum are supported. That was already quite a stretch when minver
was 2.3 and none of the Nix versions between 2.4 and 2.23 were packed
anymore. But it's impossible for us to test all these non-LTS versions
anyway: We don't have Nix 2.18, 2.19, 2.20, 2.21, 2.22, 2.23, 2.25, 2.26
and 2.27 available in Nixpkgs at the time of this writing.
With their policy around `builtins.nixVersion`, Lix forces our hand: We
need to replace minver.nix with a "feature detection" mechanism.
This PR introduces the first two features:
- The availability of `builtins.nixVersion`: If this is not available,
the version of Nix is so old, that we surely don't support it anymore.
- The value of `builtins.nixVersion` being greater or equal to 2.18.
Note, that this does **not** imply support for Nix 2.18. Instead,
explicitly supported versions of Lix and Nix are only these that we
actually test against.
If, eventually, we realize that the supported versions have advanced and
Nixpkgs has adopted a feature only available in newer versions, we will
have to add a feature check for this.
Put differently: The list of features in `minfeatures.nix` is not
expected to be complete. It's a list of known-to-be-bad conditions that
will cause problems when evaluating Nixpkgs. Their only purpose is to be
able to show a helpful error message. Some other versions might also not
be supported, but might fail with more subtle errors. That's just
reality and has always been the case previously as well.
We are hitting a long tail of problems at work related to old nix-direnv
sneaking old nix versions in that would be fixed by
https://github.com/nix-community/nix-direnv/pull/513, except that the
issue is that nix-direnv itself is too old.
It would at least be very helpful to print out *what* ancient nix
version is at fault.
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
