The Nix sandbox is a hidden input
9 points by abidingabi
9 points by abidingabi
Including the sandbox-paths in the derivation would make Nix completely unusable. Suppose you did fold sandbox-paths into the output hash by having it in the derivation. My busybox is busybox-1.37.0 at one store path; yours is a different version at a different path. The same derivation would then hash to different outputs on our two machines, and binary-cache sharing across would collapse.
I don’t understand why this would be an issue. The whole point of Nix is to make implicit dependencies explicit, and to only substitute things which are “the same” according to that standard. Why would it be an issue with the sandbox?
The issue is any build sandbox will remain "leaky" in a sense,
Take for example broken hardware, i.e. a CPU with a buggy FPU for which floating point instructions are used during the build. Running the same build on different machines can result in drastically different output builds (pathologically so, if you want to construct an example like the one in OP). It would not be reasonable to take some kind of machine hash into the derivation, even though the build machine is in a real sense an input/dependency of the computation you're running.
True, but pinning the sandbox packages would still be an improvement over not pinning them, or wouldn't it? I think that was the key point of the parent comment, making only packages explicit (i.e. what can be made explicit cheaply) and not everything in some absolutist way.
What is the status on ca-derivations? I feel they have been in development/unstable for over 5 years now.