doc(lint-absolute-path-literals): edit

[roberth]

Motivation

The previous explanation was vague and meandering.

The new text is structured around the two use cases and their disadvantages, so that it's easier to understand the context in which the arguments are made.
The subjective arguments are largely replaced by concrete ones, such as the accidental store copying risk and the difficulty of version-controlling non-hermetic expressions.

Context

@Ericson2314 and I did some explaining in NixOS Discourse
Remove All Absolute Path Literals From Nixpkgs. I don't think we would have had to explain as much with this text in place.

I wanted to make some recommendations, but "use the right type from the get go" feels like gaslighting, because Nixpkgs lib.fileset has an unresolved false positive that's blocked on e.g. an isHostRoot primop, and transitively on virtual path value stuff.

---

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/remove-all-absolute-path-literals-from-nixpkgs/77245/16

[Ericson2314]

Thanks @roberth, I like this! I wonder if a few block-code-quote examples would help make it even clearer though?

[roberth]

Not sure, to be honest. The literals are pretty simple, and I don't think the two use cases really need it.
If you have something in mind, I'd be happy to review it.

[Ericson2314]

These are sort of off the cuff examples. But maybe some of the tricky cases we found in Nixpkgs would be even more useful?

[roberth]

I think it's good to keep them simple.
The lib ones were trickiest but that's less reference documentation, more "best practices" or guide material, and that's supposed to go on nix.dev.

Also we have an unsolved false positive without alternative, so we're not quite ready for this anyway.