Make data.json available in analysis scripts

[WardBrian]

It is often useful to analyze the results in the context of the data. The example we provide for the SIR model already does this by re-installing the package the data came from, but a more general solution would be to have the data.json available in the script. This style would also compose well with #179

We can do this with virtual file systems:

• https://docs.r-wasm.org/webr/latest/mounting.html#javascript-api
• https://pyodide.org/en/stable/usage/file-system.html#mounting-a-file-system

[jsoules]

Would moving to virtual file systems suggest that we should also revise the state model for those files in the reducer? Instead of keeping 2 copies in memory?

[WardBrian]

This would be something which is local to the runtime environment set-up for the scripts (e.g., inside the pyodide worker).

It arguably would be the wrong thing to do to unify this with the state model, since we explicitly would not want edits in the data to be visible in the analysis script if the sampler isn't re-run first

[magland]

Why not make it available as a data variable, as in the data generation scripts? Maybe I'm missing exactly what you are proposing.

[WardBrian]

We could try. I think that solution would require more work, for ultimately not much gain.

1. We'd have to decide how to parse it into an R/Python object. If the user wanted something else, they're going to have to write more code anyway. If it's a lot of data, parsing it when they don't need it would also be a bummer
2. The next feature I'm working on is Optional shim code when downloading a project with scripts #179, and the less 'magic' we have the better.
   The user loading it from ./data.json would mirror exactly what they'd do when running locally.

[magland]

Okay makes sense.