lib/types: check paths in pathWith with hasStorePathPrefix

[illdefined]

This permits usage of content‐addressed derivations and has the added benefit of checking normalised paths.

We could as an alternative introduce a function to check if a string is a store path prefix that works directly on strings, without producing a temporary path.

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.

[pillowtrucker]

the builds on contentAddressedByDefault are still broken despite the other two PRs being merged

[illdefined]

the builds on contentAddressedByDefault are still broken despite the other two PRs being merged

It is still blocked by at least this PR getting merged. So far I have opened an individual PR for every subsystem I touch, but perhaps it would be better to collect them all in a single PR.

[pillowtrucker]

I'm merging into my own fork to try to update my system so I'll let you know if it worked at least

[pillowtrucker]

it appears so, but it's going to take a while for it to churn all the packages and I have to leave my computer for a while

[pillowtrucker]

yeah this removes the error on my machine. At this point I don't think it would be very useful to refactor the PRs, since two have already been in master for weeks 🤷
It would be nice if contentAddressedByDefault was actually in the test suite.. but that's not the place to discuss that I guess

[pillowtrucker]

@illdefined I'm sorry but I don't know how to resolve a conflict in someone else's pr branch, maybe I don't have the permissions, I've done a quick fix on my branch tracking master with this fix in it https://github.com/pillowtrucker/nixpkgs/tree/fix-ca-dervs

[pillowtrucker]

thanks

[illdefined]

Is it acceptable to check the path with hasStorePathPrefix, which involves converting the option value to a path, or should I try to find an alternative solution that only operates on strings?

[pillowtrucker]

@robeth @infinisil @hsjobeki unless there are issues with the style, could someone please OK this? I've built several generations of a full desktop system with this and it seems fine.

[hsjobeki]

Is it acceptable to check the path with hasStorePathPrefix, which involves converting the option value to a path, or should I try to find an alternative solution that only operates on strings?

Hm, this could be a small regression. Using discardStringContext now would discard the context if it's a store-path. Which then means you can no longer nix-build it.
Where this was possible before. I'd like to keep isString unless some concrete example can be shown why we need to discard the context.

[illdefined]

Is it acceptable to check the path with hasStorePathPrefix, which involves converting the option value to a path, or should I try to find an alternative solution that only operates on strings?

Hm, this could be a small regression. Using discardStringContext now would discard the context if it's a store-path. Which then means you can no longer nix-build it. Where this was possible before. I'd like to keep isString unless some concrete example can be shown why we need to discard the context.

The context is only discarded for the purpose of checking. The option value retains any context.

[hsjobeki]

carded for the purpose of checking. The option value retains any context.

Ah yeah, my mistake right. 👍