lib/types: add types.pathNotInStore

[jfly]

This option parallels our existing types.pathInStore type. This is
useful for when a module needs a path to a file, and wants to protect
people from accidentally leaking that file into the nix store.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[roberth]

Seems like a good idea, although the idea seems similar to an earlier PR. Maybe @infinisil knows the status of that?

I think you'll want isString, because isStringLike also accepts path values, which are added to the store when interpolated.
Supporting derivations also doesn't seem right for a type like this.

I think in many cases, users of the type will want not just path strings, but absolute path strings.
It seems that we're in the process of creating a messy api with many distinct type names for unclear use cases. Perhaps it'd be better to do something like this?

pathWith { store = false; absolute = true; }

I'd like a more compositional style (e.g. set-like operations on types), but I'm not sure that it's actually nicer for users. Probably the type description - ie docs - would suffer as well.

[jfly]

I think you'll want isString, because isStringLike also accepts path values, which are added to the store when interpolated.

Fair, changed.

I think in many cases, users of the type will want not just path strings, but absolute path strings.

Yeah, you'll see I am checking if the first character is a /. Agreed that this is messy/unclear.

Perhaps it'd be better to do something like this?

pathWith { store = false; absolute = true; }

I like that. Happy to implement that, but first I'll wait to hear back from @infinisil about the status of the earlier PR you referenced.

[jfly]

@infinisil, not urgent, but quick ping on this PR.