Nix version used

[vcunat]

NixPkgs has lib/minver.nix denoting limit on Nix version (2.0 ATM), but I know of no automation actually checking that committed code evaluates with such an old Nix. Perhaps OfBorg should run (one of) its evals with Nix 2.0.x?

[FRidh]

Quoting @LnL7

Definitively, however in it's current form it's not really possible to use a different version depending on the target branch so changing it there would apply to everything.

Even only evaluating after merge would already be helpful. Potentially annoying, but at least it signals the issue timely.

Original issue regarding the use of SRI hashes in Nixpkgs NixOS/nixpkgs#89275

[vcunat]

🤔 instead of Borg we could perhaps make the check a normal build job, and make the channels depend on it. (EDIT: though I'm not sure how much it's hard to use different nix inside a nix build.)

[FRidh]

Something like the following?

$ cat default.nix 
let
  nixpkgs = fetchTarball "channel:nixos-20.03";
  pkgs = import nixpkgs {};
  minver = import (fetchTarball "channel:nixos-19.09") {}; # Should import minver.nix for this and use a mapping to fetch Nix(pkgs).
in pkgs.runCommand "minver-test" {
  buildInputs = [ minver.nix ];
} ''
  NIX_STATE_DIR=/build/var/nix nix-env -f ${nixpkgs} -qa --drv-path --meta --xml
  echo success > $out
''

edit:

To be clear, we would not fetch tarballs. nixpkgs would be the current Nixpkgs. The minver Nix would likely need to be part of the current Nixpkgs.

[vcunat]

If it should be in NixPkgs, e.g. a dependency of the tested job, I'd want to avoid import-from-derivation. (Sounds OK if ran separately, like in a bot.)

[FRidh]

nixpkgs here would be the current Nixpkgs. Aside from that, it is the same as how the metrics job functions. If we do it inside Nixpkgs, we should also package an old Nixpkgs. Fetching an older Nixpkgs won't be possible because Hydra won't permit it.

[LnL7]

With 1.11 -> 2.0 we evaluated everything with nix1 until the version requirement was bumped IIRC. I made a patch with which disallows the new hash types which can be applied in a similar way.

Long term I was having the same idea, move evaluation to a build and pass in the dependencies dynamically based on the target branch. That approach also works for other things, like the editorconfig check or lib tests. Main issue I see with this is that it relies on channel updates not breaking these unrelated builds.