README: Remove the pills

[roberth]

This removes the Nix Pills reference, because they are not a good introduction to the Nix ecosystem, but rather a thorough explanation of many disparate things. Reading through them might give some light bulb moments for an intermediate reader, but that does not mean that they're good for a beginner.

I've also removed the mention of infinite recursion without source location. That's an old meme for a problem that has been mostly solved. Mentioning it here has two effects

• Propagate the outdated meme
• Make users insensitive to bad errors. Learned helplessness. That kind of thing. What we really want is for them to report bad error messages, so that they can be fixed. And they can be fixed; just report them at NixOS/nix

Description

Checklist

• Change is backwards compatible.

• Code formatted with ./format.

• Code tested through nix-shell --pure tests -A run.all or nix develop --ignore-environment .#all using Flakes.

• Test cases updated/added. See example.

• Commit messages are formatted like

  {component}: {description}
  
  {long description}
  

  See CONTRIBUTING for more information and recent commit messages for examples.

• If this PR adds a new module

  • Added myself as module maintainer. See example.

[roberth]

Here's the most recent testimonial, fwiw https://ersei.net/en/blog/its-nixin-time#the-part-in-which-i-make-

[ncfavier]

It would be good to replace it with something better. Do you feel like a good introduction to Nix (at least the parts that are relevant for HM) exists at the moment?

[roberth]

It would be good to replace it with something better.

I don't know if that's good. I think the audience can already edit config files in arbitrary configuration languages, so they would know at what point they need to learn more.

Maybe the one on nix.dev is at least better than Nix Pills but I don't think home manager users should need it, and it's not geared towards a module system use case.

[rycee]

I think it is fair enough to remove this, ideal would be to have some nice alternative, like @ncfavier mentioned.

About the infinite recursion, the thing I see people do over and over again is something along the lines of

{
  imports = [ (if pkgs.stdenv.isLinux then ./foo.nix else ./bar.nix) ];
}

which inevitably will lead to an infinite recursion error that (at least in version 2.13.3) doesn't really give any clear hint of what actually is the problem. If there is one error case that I wished was handled better, it's this one. I've occasionally thought about whether it wouldn't be possible to catch this in the module system itself.

[roberth]

@rycee seems feasible to improve on. Either

• return a single detailed message A addErrorContext-like primop for explaining common infinite recursion mistakes NixOS/nix#8629, or
• make the trace readable, on point, and enabled Show addErrorContext traces by default NixOS/nix#7553

Technically the information is in there, but I can hardly blame someone for not reading the trace, considering the length and verbosity. So yeah, the improvements aren't complete yet, but "infinite recursion at unknown location" specifically should already be a thing of the past. We do still have something like "stack overflow at unknown location", but that is for diverging computations, not lazy fixpoints, and it is far more rare and not caused by the module system to my knowledge.

[rycee]

@roberth Thanks, yes something that can insert additional information in the trace would probably do quite nicely. As-is, while each trace entry does have a location, none of them actually seem to give you a hint about the actual error location. With this error context, one could perhaps, at least, add some reference to the module file containing the problematic imports line.

Edit: Concerning my "I've occasionally thought about whether it wouldn't be possible to catch this in the module system itself" line earlier. I believe my thought was along the line of replacing non-special module argument with, for example,

pkgs = abort "Cannot use pkgs while loading modules"

when collecting modules. And then swap them out with the actual arguments when evaluating the modules. I have not put much thought into that, though so I don't even know if it would be possible to accomplish this argument swap maneuver in a reasonable way. If it is possible, then I do believe that it would allow us to give a quite precise error message in the "imports with pkgs reference" case.