How can I get CLI marimo to build against the versions that pyodide will install?

[DOSull]

Note I am aware that this question might be completely misconceived because my understanding of a lot of the clever stuff that marimo-WASM-pyodide is doing to make any of this possible is somewhat limited!

Really enjoying using marimo, which for me fills a particular need to develop a web interface to a small library I've been working on.

One thing I am running into which is confusing me and making debugging difficult is that the versions of python wheels that the marimo CLI in notebook editing mode will install diverge from the versions that a running app on the web will pull from pyodide, sometimes quite widely. This might not be the reason I see errors on the app that I can't reproduce locally, but it's a source of uncertainty and confusion, and it would be nice to be able to force the CLI editing mode to better replicate the app experience.

I've tried using marimo edit --sandbox my-app.py but have noticed that this only controls the versions of package explicitly imported by my code and not the secondary dependencies. In my case that leads for example to numpy 2.2.4 running in the CLI while on the web my app only gets to work with numpy 2.0.2!

So my question: is there a way to force CLI marimo edit my-app.py to pull only versions of packages that the hosted running app will have access to from pyodide?

[mscolnick]

Short answer is no.

And its not always possible. Each pyodide version comes with a lockfile pointing to a set of versions but they are pinned (and not a range), so you are somewhat* forced to use their versions: https://pyodide.org/en/stable/usage/packages-in-pyodide.html

*I say somewhat because you can host your own pyodide lockfile (differs from uv and other package managers) that points to versions you use. The problem is that you will need to generate this lockfile which isn't that easy from outside pyodide.

We do want a seamless local python <> browser back and forth, so I can think of some solution that may help.

[DOSull]

That's unfortunate.

For what it's worth, I am not entirely certain that it's testing in edit mode on different module versions vs what is loaded when the app is web hosted that is the problem, but it would remove an additional variable from the mix (another variable in relation to the kinds of errors I am seeing is differences in floating point between JS and python, which no amount of aligning of module versions will resolve...)

One thing perhaps worth noting in this regard is that the combination of module versions delivered by pyodide in my use-case is one that conda is unable to resolve! Pyodide delivers fiona 1.9.5 and conda insists that I revert numpy all the way back to 1.26.3 to accommodate that requirement! I'm not sure what's going on there, and it's clearly not a marimo issue, just another dimension to python dependency hell.

As far as solutions go it would certainly be good to have some flag in the CLI marimo edit my-app.y situation where you could request that it load imports from pyodide and not from the local environment. Currently if the CLI notebook is missing a module it installs it into the environment, and it defaults to installing the latest version. I can request other versions from a dropdown, but this means I have to carefully check which versions pyodide is currently delivering. Perhaps there's a way to somewhat emulate the likely webhosted experience by pulling modules via micropip from pyodide. It would make the notebook startup a lot slower, but might be a worthwhile addition.

[mscolnick]

Yea this is a good idea to help alleviate this. We could add a little icon in the dropdown that shows the Pyodide version used. It would be much hard though for transitive dependencies (which could make that approach not as useful).