The comment "The -I flag pins the Nixpkgs revision to an exact Git revision, leaving no doubt about which exact version of Nix packages will be used." makes my eyes glaze over. How do I get that git revision? Is a user really expected to do this? In practice I don't think I'd use a shell one-liner this way, I'd use a shell.nix, right?

I think this example is bringing in immutability a bit too early, even though it's a defining feature.

The next bit https://nixos.org/guides/towards-reproducibility-pinning-nixpkgs.html#pinning-nixpkgs talks more about this, and feels like the good stuff. But it abandons the python example from before, and so I can't figure out how to use niv.

I want to say something like niv add 'python38.withPackages (packages: [ packages.django ])' to continue building on the previous example of installing Django, but that doesn't work. Even niv add python38 doesn't work.

  FATAL: One or more packages failed to update:
  python38.withPackages (packages: [ packages.django ]): Update failed: Key could not be found: url_template
  CallStack (from HasCallStack):
    error, called at src/Niv/Update.hs:80:25 in niv-0.2.21-K4hQ3qL7WtG6yW48qVS1p3:Niv.Update
ERROR: ExitFailure 1

Not a friendly error message, and I feel like the doc is missing a chance to continue to build on the previous page.

Now that I think of it, python38.withPackages isn't explained in terms of the nix-env -qaP command; teach me how to fish and figure out what package names I should use? nix-env just gives me:

nixpkgs.python        python-2.7.18
nixpkgs.python2       python-2.7.18
nixpkgs.python27Full  python-2.7.18
nixpkgs.python2Full   python-2.7.18
nixpkgs.pythonFull    python-2.7.18

-- where is the python38 coming from? (By which I mean, how does a new user figure out what python3* exist to use?)

One thing the Rust docs (and ecosystem more generally) do is liberally link between different sources of information, so if there is a doc repository hosting the python38 and explaining the withPackages args, linking it so that I can learn about that source of package information would be useful.

Final note -- I feel like this brushes over some core concepts: "You can use the generated nix/sources.nix with a top-level default.nix"

Before you tell me to do a default.nix, maybe explain that and shell.nix and why they are awesome (AIUI these are some of the very cool bits of the nix plumbing).

In reply to @tpw_rules:matrix.org
Sandro 🐧: nix-env -qaP is definitely a thing to take out in your "sync with best practices" PR

In reply to @rapenne-s:tchncs.de
that's cool, someone wrote https://nixos.wiki/wiki/Specialisation after my tweag blog post. I added this section because it's a very useful use case but totally impossible to figure out (infinisil found how to do that). Could someone tell me if it's understandable? https://nixos.wiki/wiki/Specialisation#Special_case:_the_default_non-specialised_entry

In reply to @rapenne-s:tchncs.de
that's cool, someone wrote https://nixos.wiki/wiki/Specialisation after my tweag blog post. I added this section because it's a very useful use case but totally impossible to figure out (infinisil found how to do that). Could someone tell me if it's understandable? https://nixos.wiki/wiki/Specialisation#Special_case:_the_default_non-specialised_entry

In reply to @rapenne-s:tchncs.de
Jan Tojnar yes this can be inline within the imports but I find it very not practical