Get rid of the settings-dependent writeDerivation wrapper#15219
Merged
xokdvium merged 1 commit intoNixOS:masterfrom Feb 14, 2026
Merged
Get rid of the settings-dependent writeDerivation wrapper#15219xokdvium merged 1 commit intoNixOS:masterfrom
writeDerivation wrapper#15219xokdvium merged 1 commit intoNixOS:masterfrom
Conversation
It was a crude hack that this one low-level function was dependent on the high-level read-only mode setting --- all the more so because rather than making derivation writing fail, that setting made it silently "succeed" why not actually writing the derivation. (Also, for context, we didn't have an such behavior for any other store-mutating operations, just for this one function.) I have gotten rid of the wrapper, and updated the call sites accordingly. - For the ones that should remain dependent on this setting, I made this explicit, and added a comment. - For others, surrounding operations assumed writability (e.g. we had written something before, or were about to try to read back the written derivation after), and so I just made those do the underlying `Store::writeDerivation` operation.
github-actions
bot
added
new-cli
Ericson2314
changed the title
writeDerivation wrapper
xokdvium
approved these changes
Feb 14, 2026
xokdvium
reviewed
Feb 14, 2026
Comment on lines
+311
to
+315
| /* Quite dubious that users would want this to silently suceed | ||
| without actually writing the derivation if this setting is | ||
| set, but it was that way already, so we are doing this for | ||
| back-compat for now. */ | ||
| auto ret = nix::settings.readOnlyMode ? nix::computeStorePath(*store->ptr, derivation->drv) |
Contributor
There was a problem hiding this comment.
Indeed, ideally the behaviour of C API functions isn't affected in an observable way. The method by which we do stuff vs what the end result is a different matter.
@roberth, what do you think?
IMO it seems reasonable to fix this as a bugfix. I doubt any caller is using this hack to just compute a store path.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
It was a crude hack that this one low-level function was dependent on the high-level read-only mode setting --- all the more so because rather than making derivation writing fail, that setting made it silently "succeed" while not actually writing the derivation. (Also, for context, we didn't have an such behavior for any other store-mutating operations, just for this one function.)
Context
I have gotten rid of the wrapper, and updated the call sites accordingly.
For the ones that should remain dependent on this setting, I made this explicit, and added a comment.
For others, surrounding operations assumed writability (e.g. we had written something before, or were about to try to read back the written derivation after), and so I just made those do the underlying
Store::writeDerivationoperation.Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.