You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we include the store directories in store paths in JSON. This makes for nice-looking JSON that is easy for humans to manipulate.
However, it comes at a cost in that it breaks almost all JSON frameworks somewhat: the store dir is not actually part of the store path data type, and so it must be smuggled in somehow. We work around it with ad-hoc code in C++, but in other languages the expectation is for JSON to be very "regularly" defined, e.g. with traits/type classes, and so forcing things to be ad-hoc carries a higher costs.
Here are some options:
Just don't include a store dir any more. The JSON would like like e.g.
Parse any store dir. As long as the path ends with the store object file name, and isn't something like /nix/store/0nxvi9r5ymdlr2p24rjj9qzyms72zld1-bash-interactive-5.2p37/bin/bash, we can just peal off all leading directories and just parse its "basename". but in the to-JSON direction, we still need to come up with a store directory out of thin error. That breaks the languages infrastructure.
In fancier languages, do the moral equivalent of StorePath<"/Nix/Store">, which allows us to smuggle in the store dir at compile time. This works, but leaves less fancy languages in the lurch. It replaces one source of intimidating complexity with another.
Just do nothing, because we care more about the human case than the machine case.
Currently, we include the store directories in store paths in JSON. This makes for nice-looking JSON that is easy for humans to manipulate.
However, it comes at a cost in that it breaks almost all JSON frameworks somewhat: the store dir is not actually part of the store path data type, and so it must be smuggled in somehow. We work around it with ad-hoc code in C++, but in other languages the expectation is for JSON to be very "regularly" defined, e.g. with traits/type classes, and so forcing things to be ad-hoc carries a higher costs.
Here are some options:
Just don't include a store dir any more. The JSON would like like e.g.
We choose this one
Parse any store dir. As long as the path ends with the store object file name, and isn't something like
/nix/store/0nxvi9r5ymdlr2p24rjj9qzyms72zld1-bash-interactive-5.2p37/bin/bash, we can just peal off all leading directories and just parse its "basename". but in the to-JSON direction, we still need to come up with a store directory out of thin error. That breaks the languages infrastructure.In fancier languages, do the moral equivalent of
StorePath<"/Nix/Store">, which allows us to smuggle in the store dir at compile time. This works, but leaves less fancy languages in the lurch. It replaces one source of intimidating complexity with another.Just do nothing, because we care more about the human case than the machine case.
HashDerivedPath/ deriving pathDerivedPath#14344OutputsSpec::AllJSON be"*"not["*"]#14528Realisation/ build trace entryRealisation#14065ValidPathInfocafields structural, not string Modifications to the JSON formats forDerivationandValidPathInfo#14493ValidPathInfo,NarInfoJSON instances, but don't yet use in the CLI #14503--json-formatfornix path-info#14704DerivationinputSrcsandinputDrvstogether asinputs.{srcs,drvs}Modifications to the JSON formats forDerivationandValidPathInfo#14493DerivationOptionsDerivationOptions#14507DerivationOptionsJSON and clean up unit tests #14471StorePath,DerivingPath, etc. Parse deriving paths inDerivationOptions#14506DerivationOptionsinDerivationStoreDerivationOptioninsideDerivation, put in JSON format #10760BuildResultDummyStoreJSON impl and Schema forDummyStore#13942