toString on path value in store drops string context

[roberth]

Describe the bug

toString on a path value that references a store path does not create a string context.

I suppose path values weren't designed to contain store paths, but flakes do it. I don't know how relevant this is after lazy trees, but it can still be encountered with import "${./.}" if default.nix references relative paths.

Steps To Reproduce

builtins.getContext (toString /nix/store/aaxda5ywpsjwr1j9fkrrks1p0iyaxg97-source)
{ }

or for a realistic example, #7796 (comment)

     runCommand "bad" { path = toString ./.; } ''
       echo "$path"
       ls "$path" || echo "./. is not a proper path and is thus not accessible"
     '';

Expected behavior

toString ./. preserves string context when ./. is in the store?

On the other hand, toString /var does not and can not have a string context, so perhaps we shouldn't project this expectation onto toString.

nix-env --version output

Additional context

Add any other context about the problem here.

Priorities

Add 👍 to issues you find important.

[sternenseemann]

toString ./. preserves string context when ./. is in the store?

This would be extremely confusing. The whole point of toString is to convert paths into strings without incurring any kind of string context, while "${path}" preserves it (albeit by re-dumping the path even if it is in store). I could see an argument for treating the path specially depending on whether it is already in builtins.storeDir or not in the latter case, but not in the former.

[roberth]

On the other hand, toString /var does not and can not have a string context, so perhaps we shouldn't project this expectation onto toString.

[changing] This would be extremely confusing.

I think this is the right interpretation.
Path values simply don't have a string context, until you copy them using string interpolation / concatenation.

So then this would be a documentation and/or error messages issue; not a bug.

We should perhaps discourage the use of

/. + someStorePathString

and #6530 should also help prevent this, to the degree that flake copying to the store is the problem here.