Better handling for non-deterministic evaluations #7

Open
opened 2026-04-15 13:09:10 +00:00 by ma27 · 0 comments
Owner

With pure mode not being feasible for non-flakes, it's easy to introduce impure stuff by accident. However, evolive fingerprints inputs and doesn't re-evaluate already existing things. In other words, it assumes deterministic eval.

The idea discussed with @raito would be

  • have n-e-j / Lix's libexpr indicate the usage of non-deterministic language features (e.g. builtins.currentTime). We should await current developments in libexpr and then signal non-determinstic eval in nix-eval-jobs in Lix.
  • if this flag is set for at least one job, mark the parquet as impure in the metadata, don't reuse the result when an impure fingerprint exists already (perhaps allow with a "really-really-cache" flag to still return existing results for some use-cases).
With pure mode not being feasible for non-flakes, it's easy to introduce impure stuff by accident. However, evolive fingerprints inputs and doesn't re-evaluate already existing things. In other words, it assumes deterministic eval. The idea discussed with @raito would be * have n-e-j / Lix's libexpr indicate the usage of non-deterministic language features (e.g. `builtins.currentTime`). We should await current developments in libexpr and then signal non-determinstic eval in nix-eval-jobs in Lix. * if this flag is set for at least one job, mark the parquet as impure in the metadata, don't reuse the result when an impure fingerprint exists already (perhaps allow with a "really-really-cache" flag to still return existing results for some use-cases).
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
botanix/evolive#7
No description provided.