Upstream C++ Nix switched to storing a pair of a hash and name, rather raw file path, for it's StorePath type. So far, this is just like us. However, there is no store type intrinsically associated with the store path in C++ Nix; if you wish to convert it to a concrete file path, you need to provide a store too so the missing information can be filled in.
I think this is better than what we do. I understand we were using the type level trickery to mimick what old Nix did, but I think store-agnostic paths are better than store specific ones----all the moreso with things like content-addressed derivations making the /nix/store less and less important. (You can always relocate content-addressable outputs, so it doesn't matter if two stores agree.) Now that Nix made the switch to store-agnostic paths, we should too.
sorki
commented
4 years ago
Upstream C++ Nix switched to storing a pair of a hash and name, rather raw file path, for it's
StorePathtype. So far, this is just like us. However, there is no store type intrinsically associated with the store path in C++ Nix; if you wish to convert it to a concrete file path, you need to provide a store too so the missing information can be filled in.I think this is better than what we do. I understand we were using the type level trickery to mimick what old Nix did, but I think store-agnostic paths are better than store specific ones----all the moreso with things like content-addressed derivations making the
/nix/storeless and less important. (You can always relocate content-addressable outputs, so it doesn't matter if two stores agree.) Now that Nix made the switch to store-agnostic paths, we should too.