I learn something new about Nix every day.
25 Likes
Is this a bug?
This is tough to say. 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 think this is true, or if it is true it would also behave like that for any other dependency from nixpkgs. If you provide a flake producing some derivation, you’ll use that flake’s pinned version of nixpkgs for the derivation’s dependencies, so even if you use a different version of BusyBox in your nixpkgs, everyone will use the same nixpkgs to build this one derivation.
This is why many flakes tell you not to use inputs.<dep>.inputs.nixpkgs.follows = "nixpkgs";, as doing that would cause everyone to use a different BusyBox to compile the dep.
(Hello again Farid 
I saw this from lobsters but I don’t have an account there)
That part wasn’t clear.
What i meant:
If you allow it to be configurable AND ALSO become an input, then that will modify the hash unecessarily.
The busybox on NixOS is set by the release/commit you are on, so if you tried to install anything outside that commit, you will never get a cache hit.
Also, Hello!
2 Likes
Ah yeah, that’s true of any CLI flag that causes changes in the inputs to a derivation, so I don’t think it’s that surprising. The flag probably shouldn’t exist though.
well that’s the point; very few flags do change those… and they usuall have crazy stuff like “impure” in the name not “sandbox” 
Having a “pure hermetic” builder and then poking a bunch of holes in it…seems counter productive 
3 Likes
Would be a good fit for this feature?