Put "Best practices" parts where they belong about nix.dev

[9999years]

Unfortunately I don't see "just move" happening because there are so many moving parts. There's barely a chance to not do rewriting simply to be able to fit things in.

We don't need to make a monolithic ticket for this. It's OK to move it and then create follow-up tickets for rewriting the relevant material. Small incremental improvements are easier to work with.

[fricklerhandwerk]

I'd very much support that. That's the sort of clean-up I always had in mind. Unfortunately I don't see "just move" happening because there are so many moving parts. There's barely a chance to not do rewriting simply to be able to fit things in.

The Technically Correct but very expensive way to do it would be this (ordered roughly from most to least involved):

• Move the reproducible Nixpkgs configuration tip to the configuration section of the Nixpkgs manual (which is a mess and needs a complete rewrite to even find a good place for this)
• Merge pinning Nixpkgs and the other pinning Nixpkgs (I have a very messy WIP branch that got confused on the path down a rabbit hole) and add it to the Nix manual
• Rewrite the the lookup paths tip and wire it up so there is no duplication with e.g. nix-channel documentation
• Add nested attribute set update tip to the troubleshooting section, move the examples to the Nix manual operators page, and extend the lib.recursiveUpdate piece with the problem statement and link to that Nix manual page.
• Rewrite the reproducible source paths example to use builtins.derivation
• Find places in the language section for the other tips. (Technically there is also a licensing issue, because nix.dev is CC-BY-SA and Nix is LGPL. sigh)

And on the way keep all URLs working by adding redirects appropriately, synchronising PRs across repos once the information has a new place.

But maybe we can get this done piecemeal.