"Break" the build on non-unstable Nixpkgs version

[samueldr]

The main idea would be to check the Nixpkgs version (e.g. 20.09) and if lower error out of the build.

Though, this should only error out if it's known bad, so the next update, (21.03) should add a warning that it's only known to successfully build on Unstable, and that success may be variable. Once it is known that it won't build against, increase the minimum required version.

So, in this scheme, we have two variables:

• minimumRequiredNixpkgsVersion break when the current version is lower
• testedNixpkgsVersion warn when the current version is lower

This would be a build-time UX improvement, reducing the risks that a user (rightfully) won't know why the builds fail.

This would help for issues like #166.

[ingenieroariel]

This can be done by using nix flakes to pin to a particular unstable commit. Allowing both the developer and end users more flexibility. With this we can pin a configuration to both a nixpkgs and a mobile-nixos version.

{
  inputs.nixpkgs.url = github:NixOS/nixpkgs/nixos-unstable;

  outputs = { self, nixpkgs }: {

    nixosConfigurations.dodo = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      modules = [
        nixpkgs.nixosModules.notDetected
        ./configuration.nix
      ];
    };
  };
}

flake.lock

{
  "nodes": {
    "nixpkgs": {
      "info": {
        "lastModified": 1592117084,
        "narHash": "sha256-jcnJkno/Vt+iWcZhhZ2bBUGABGondsM5UBgnD528npQ="
      },
      "locked": {
        "owner": "NixOS",
        "repo": "nixpkgs",
        "rev": "0a146054bdf6f70f66de4426f84c9358521be31e",
        "type": "github"
      },
      "original": {
        "owner": "NixOS",
        "ref": "nixos-unstable",
        "repo": "nixpkgs",
        "type": "github"
      }
    },
    "root": {
      "inputs": {
        "nixpkgs": "nixpkgs"
      }
    }
  },
  "root": "root",
  "version": 5
}

[samueldr]

Until flakes is a feature part of Nix stable, this will not be made using flakes...

Additionally, Mobile NixOS has to be able to be used by the end-user's channel revision of their choice.

Pinning the version of Nixpkgs is not a goal. This is because I don't want this project to decide which Nixpkgs version the user uses, they could be using their own fork, or requiring the latest release for security updates!

When Mobile NixOS will be a bit more stable, it will get stable branches as NixOS does, so "breaking" the build for Nixpkgs releases too low will not be an issue.

[ingenieroariel]

Pinning the version of Nixpkgs is not a goal. This is because I don't want this project to decide which Nixpkgs version the user uses, they could be using their own fork, or requiring the latest release for security updates!

Using nix flakes for mobile-nixos and given that nixpkgs already uses it would be less about mobile-nixos forcing a version on a user and more about a user being able to pin both on a flake.nix, share on a gist, etc.

For the time being, your suggestion to look at latest builds in Hydra and then find the last successful build I think satisfies most of the early adopter needs. We just need to mention it more prominently if possible. https://hydra.nixos.org/build/123368707

When Mobile NixOS will be a bit more stable, it will get stable branches as NixOS does, so "breaking" the build for Nixpkgs releases too low will not be an issue.

True