lix-project/lix

Fork 58

`nix-instantiate --eval` ambigously fails to create -source storepath #271

New issue

Open

opened 2024-05-06 00:36:00 +00:00 by ckie · 4 comments

ckie commented

2024-05-06 00:36:00 +00:00

Member

Describe the bug

nix-instantiate --eval sets settings.readOnlyMode too opportunistically,
and this makes lix sad because here
we silently noop fetchToStore if readOnlyMode instead of
telling the user if we computed path and it isn't already there.

with --read-write-mode, readOnlyMode is not set, and everything is happy (:

there are two bugs here: (1) silent fetchToStore noop in r/o mode (2) --read-write-mode is annoying to write

Steps To Reproduce

git clone git@git.lix.systems:ckiee/lix-reprod-niv-override.git
cd […]
# bork:
echo '"'$RANDOM'"' > awa/meow.nix ; NIV_OVERRIDE_ckiesite="$(realpath ~/git/lix-reprod-niv-override/awa)" nix-instantiate --eval reprod.nix ; cat result
       error: path '/nix/store/qi25lcmspv49g52sbzhk614d0fnw0nmd-awa' is not valid
# awawa happy:
echo '"'$RANDOM'"' > awa/meow.nix ; NIV_OVERRIDE_ckiesite="$(realpath ~/git/lix-reprod-niv-override/awa)" nix-instantiate --eval --read-write-mode reprod.nix ; cat result

`nix --version` output

nix (Lix, like Nix) 2.90.0-lixpre20240504-8dfb30a

Additional context

cppnix also has (some?) of this bug.

previous: #270

## Describe the bug `nix-instantiate --eval` sets `settings.readOnlyMode` too opportunistically, and this makes lix sad because [here](https://git.lix.systems/lix-project/lix/src/commit/7cffd7a3b550deb3b2780780fd0226cbc649da9b/src/libfetchers/fetch-to-store.cc#L21) we silently noop `fetchToStore` if `readOnlyMode` instead of telling the user if we computed path and it isn't already there. with `--read-write-mode`, `readOnlyMode` is not set, and everything is happy (: there are two bugs here: (1) silent fetchToStore noop in r/o mode (2) `--read-write-mode` is annoying to write ## Steps To Reproduce ``` git clone git@git.lix.systems:ckiee/lix-reprod-niv-override.git cd […] # bork: echo '"'$RANDOM'"' > awa/meow.nix ; NIV_OVERRIDE_ckiesite="$(realpath ~/git/lix-reprod-niv-override/awa)" nix-instantiate --eval reprod.nix ; cat result error: path '/nix/store/qi25lcmspv49g52sbzhk614d0fnw0nmd-awa' is not valid # awawa happy: echo '"'$RANDOM'"' > awa/meow.nix ; NIV_OVERRIDE_ckiesite="$(realpath ~/git/lix-reprod-niv-override/awa)" nix-instantiate --eval --read-write-mode reprod.nix ; cat result ``` ## `nix --version` output `nix (Lix, like Nix) 2.90.0-lixpre20240504-8dfb30a` ## Additional context cppnix also has (some?) of this bug. previous: https://git.lix.systems/lix-project/lix/issues/270

ckie added the

bug

labels

2024-05-06 00:36:00 +00:00

lix-bot commented

2024-06-03 09:29:52 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

commit message in cl/1160 ("Add a clearer error message for InvalidPathError during evaluation")
comment in cl/1160 ("Add a clearer error message for InvalidPathError during evaluation")

This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/1160](https://gerrit.lix.systems/c/lix/+/1160) ("Add a clearer error message for InvalidPathError during evaluation") * comment in [cl/1160](https://gerrit.lix.systems/c/lix/+/1160) ("Add a clearer error message for InvalidPathError during evaluation")

lix-project referenced this issue from a commit

2024-06-16 04:29:33 +00:00

Add a clearer error message for InvalidPathError during evaluation

commentatorforall added this to the Error reporting project

2025-12-19 17:24:59 +00:00

commentatorforall added the

awaiting

author

label

2025-12-19 17:25:07 +00:00

commentatorforall commented

2025-12-19 17:25:15 +00:00

Member

does this issue still persist?

ckie commented

2025-12-19 19:09:26 +00:00

Author

Member

maybe, depending on how it's defined, what cl/1160 did is improve the error message, but @midnightveil calls the whole codepath "only possible if internal invariants are violated?".. So I think there is some debugging, to understand where we can throw a clearer error that points towards what was done wrong with some trace/location reporting.

maybe, depending on how it's defined, what cl/1160 did is improve the error message, but @midnightveil calls the whole codepath "only possible if internal invariants are violated?".. So I think there is some debugging, to understand where we can throw a clearer error that points towards what was done wrong with some trace/location reporting.

commentatorforall removed the

awaiting

author

label

2025-12-19 19:12:19 +00:00

raito commented

2025-12-22 08:32:02 +00:00

Owner

I think this issue should be split into smaller pieces, e.g. rework the overall read-only mode and the various caller assumptions. From there, we can tackle this.

This is very annoying because it requires re-architecturing to achieve well. All these APIs that switch case based on whether store can be W or not are forced to perform a pure computation of the store path letting the caller honors the fact that the path already exist or manifest it somehow later. I think this issue should be split into smaller pieces, e.g. rework the overall read-only mode and the various caller assumptions. From there, we can tackle this.