I was wondering
when is a read-write Nix store path useful? (e.g., using
- what are the implications? (reproducibility, security, etc.)
- what were the issues it was initially meant to solve? (i.e., historical hindsight)
In the blog post Scripting with Nix, there is this paragraph (emphasis mine):
nix-instantiate --read-write-mode --show-trace --eval -E 'import ./my-script.nix'
--evaltells Nix to evaluate an expression, rather than build a package.
-Eis the expression to evaluate (in this case, importing our “script” file).
--read-write-modeallows the script to add things to the Nix store (which is normally read-only).
--show-tracewill help us to debug, by showing a backtrace if a runtime error occurs.
Looking up the documentation for
nix-instantiate, the entry for
--read-write-mode option says the following:
When used with
--eval, perform evaluation in read/write mode so nix language features that require it will still work (at the cost of needing to do instantiation of every evaluated derivation). If this option is not enabled, there may be uninstantiated store paths in the final output.
Based on this description alone I would have no clue of what this actually does (and it has already been clarified…).
Investigating the source of
git blame, I found the related commits below, but they didn’t help much (or I just wasn’t able to interpret them correctly).
Rename --no-readonly-mode --read-write-mode · NixOS/nix@e4058fa · GitHub (self-explanatory)
nix-instantiate: Add a --no-readonly-mode flag
This allows running nix-instantiate --eval-only without performing the
evaluation in readonly mode, letting features like import from
derivation and automatic substitution of builtins.storePath paths work.
Having trouble to unpack this… In the end, this commit only provides a command line switch to toggle the already present
readOnlyModesetting (the predecessor of the current
As far as I can tell, this is the earliest occurence of
readOnlyMode; still not much help.