[FEATURE] Multiple py-envs in a single html file

Assuming it’s possible, having multiple, different, simultaneously available py-envs could be very useful. As an easy example, consider two interactive demonstrations of different major versions of the same library, illustrating a new feature or breaking change. Or different versions of Python showing performance improvements with runnable tests.

There could be a one-to-many relationship between <py-env> tags and other py-script tags that use them. The one-to-one case would still be the most common, so existing html files could work as-is. For the others, we could allow an optional id to connect the tags. E.g. <py-env id="foo"> could be used by name with both <py-script py-env="foo"> and <py-repl py-env="foo"> being present in the same html file, along with any additional groups like id="bar".

[fpliger]

It sounds that different options could serve different use cases. Would be good to understand the need for the many use cases, the actual effort in each option, and rough benchmark (to understand how much we actually get with each one) to help prioritize

[rth]

I was definitely hoping that the loading time addition would have been only from new packages since the packages shared by environments would have run already.

So there could be different ways to approach this,

1. creating a new Pyodide instance is similar in spirit to creating to launching separate VMs. One would get a separate Emscripten virtual filesystem, a separate Python but it’s indeed more expensive to setup. We need to benchmark how much is the overhead exactly (and it likely depends how good is the browser at caching).
2. taking the virtualenv analogy, it should be possible to keep a single Emscripten virtual filesystem, a single Python but install packages into a separate prefix/folder in the file system. This would require some work, as in particular the venv stdlib module is not available, and unlike with virtualenv it’s not possible to have multiple Python executables in this use case. Still, I imagine it should be possible and it would be lighter than option 1.
3. Finally, it’s possible to have a single set of packages, but different globals objects and different states, which would be even faster, but then you can’t indeed have the multiple versions of the same library installed, so it would likely not address this issue.