@domenkozar, thanks for your PR! By analyzing the annotation information on this pull request, we identified @edolstra, @ebzzry and @Ericson2314 to be potential reviewers

This seems to duplicate these paths in nixos-install.sh:

Also would be better to figure out a way to automate that, like nix-env -i $(curl -L -H "Accept: application/json" 'http://hydra.nixos.org/job/nixpkgs/trunk/nixStable.x86_64-linux/latest' | some magic here) (possibly by enhancing Hydra to also give some easily shell-parseable output)

Or how about this: Hydra publishes a tarball to a canonical URL with a single nix file in it containing a string with the instructions in it.

Then this default.nix calls fetchTarball on that path (no hash needed) if the version is too low (or provides a link to it if fetchTarball is missing), evaluates the contents, and then prints out the message as an error.

That requires Hydra to be online while currently you just need cache.nixos.org to be there and I've never seen it down.

@domenkozar does it? I'm just saying Hydra uploads a file to a canonical URL (it could be anywhere for all I care) after a successful build, just like it updates channels on nixos.org.

@copumpkin for example https://nixos.org/releases/nix/latest/? I'm +1 doing this more automated, but let that be second iteration :)

Yeah, that. Definitely fine to do this for now, just don't want to have long-term instructions that will rot and mislead newbies 😄

Removing dependency on wiki is exactly one step to that goal :) Fully agreed.

One thing I've noticed, it's possible to install Nix for the wrong platform and completely break it. cc @edolstra

Now that you point that out, @domenkozar, it seems like with the thing I'm describing, the tarball could contain one attribute per system, which would then serve up the correct instructions based on the actual Nix that's evaluating it.

Again, not something we need to do now, but it'll cut out one potential human screwup eventually 🐱

@copumpkin good idea, I've now refactored that to print

$ nix-build 
error: evaluation aborted with the following error message: ‘This version of Nixpkgs requires Nix >= 1.20, please upgrade:

On your platform x86_64-linux:

  $ nix-env -i /nix/store/mln2lswvkyx6x7j6pcx80cyf06fsc12m-nix-1.11.2
’

If there are no objections from @edolstra I'll merge this tomorrow.

I don't think this is a good idea, because how to upgrade Nix is system-dependent. E.g. on NixOS, installing Nix via nix-env will cause interference with the version installed in the system profile. Likewise when Nix is installed via RPM/apt.

Also, this duplicates the store paths in nixos-rebuild, which means yet another manual step to perform when doing a Nix release.

Maybe we should just remove the wiki link?

@edolstra doesn't nixos-rebuild handle Nix upgrade automatically so user shouldn't never get this error?

I think it's common for folks not to upgrade Nix (non-nixos) and we have to have a way for them to do so when nixpkgs requirement is bumped.

Maybe Nix should have some autoupgrading logic in there? Or at least warn that newer version is around.

For example pip (python installer) checks for newer versions on invocations and caches that for a while:

You are using pip version 8.0.2, however version 8.1.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

I think this PR is "good enough" until we find a better way.

It's very important for Nix installation/usage not to introduce blockers since that gives people a sense of unstable package manager, leaving them in the paradox.

@edolstra I've run into several people who have encountered the "nix is too old" message, and have even found the current wiki page confusing or misleading. Making that experience worse for them seems like the wrong direction.

A tiny bit out of context, but here is @edolstra feedback:

domenkozar: well, my objections still stand: 1) this adds yet another place where we hard-code Nix store paths; 2) the instructions would be misleading on NixOS or on any system where Nix is installed via a non-Nix mechanism (e.g. RPM) or in a multi-user installation
domenkozar: for RPM, you would end up with Nix in /usr/bin and /nix/store, and who knows which one would be used

I'll fix 1) and look into 2).

@domenkozar (I'm very late): nixos-rebuild has these fallbacks to use when it's unable to get (newer) nix the usual way: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/installer/tools/tools.nix#L41 ... but IMO we could well factor these out and use them on both places (and e.g. add a Darwin fallback).

From the manual it seems that the bash-curl method is far the easiest way to get nix onto a Linux or Darwin machine: http://nixos.org/nix/manual/#ch-installing-binary I'd think in that case it's enough to perform upgrades of nix itself by nix-env and this PR would seem a good suggestion (perhaps after extending by a note that the way might not be suitable in all cases).

Feedback requested on IRC:

Situation:

• ‘nix-env --version’ -> nix-env (Nix) 1.10
• nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion -> "17.03pre94828.ecbb932"
• uname -om -> x86_64 GNU/Linux
• Link on the wiki is 404 not found

Working solution provided on IRC:

nix-env -i /nix/store/mln2lswvkyx6x7j6pcx80cyf06fsc12m-nix-1.11.2

For the long-term solution see NixOS/nix#1113, I'd still merge something like this for short-term.

I don't think the current proposal will work on NixOS, because you can get into problems where the nix-daemon is running a too old version and just using a newer nix evaluator doesn't help. How about something more along these lines:

This version of Nixpkgs requires Nix >= ${requiredVersion}, please upgrade:

   - If you are running NixOS, use `nixos-rebuild' to upgrade your system.

   - If you installed Nix using the install script (https://nixos.org/nix/install),
     it is safe to upgrade by running it again:

        curl https://nixos.org/nix/install | sh

This one doesn't seem to be progressing. I'm closing this and implemented my suggestion above in #24017.