Replies: 2 comments 1 reply
-
That's correct -- this can happen. Part of the contract the user must adhere to get reproducibility for free in marimo is to not mutate objects in cells other than the one they are defined in. This is covered in some of our guides/best practices documentation. Tracking mutations is a huge rabbit hole, and has correctness cliffs as well as performance cliffs that are very difficult to reason about. It would require instrumenting Python code at runtime (performance cliff), and is impossible to get 100% correct (correctness cliffs). For these reasons marimo only uses static analysis in constructing its graph. marimo's execution order is reproducible in the same sense as Pluto.jl; Pluto.jl also has package reproducibility, which we currently do not have but may in the future. Hope that helps clarify things. |
Beta Was this translation helpful? Give feedback.
-
Converting this to a discussion, in case you'd like to chat more. |
Beta Was this translation helpful? Give feedback.
-
Describe the bug
In the project description and docs it's claimed several times that Marimo is reproducible and has "no hidden state".
However, I noticed, that python objects can be changed by repeated and automatic execution, so they could contain content that might not be part of the notebook anymore.
Is this behavior intended or could this be fixed? Did I oversee or misinterpret anything?
Nontheless, great work on this nice project!
Environment
Code to reproduce
Example code for repeated cell execution changing the output. First execute all cells and then repeatedly execute cell 2 and see the output of cell 3 change.
Example code for deleted content affecting cell output. First execute all cells and then delete cell 2.
Beta Was this translation helpful? Give feedback.
All reactions