Packaging

Some of the original discussion is in #38.

Here a "pyodide package" refers to the .js and .data files which form Wasm filesystem overlays.

Features that would be nice to have (unordered list for now):

• Put package building tools in a library (requirement to enable a lot of what is below)

• Packages in separate repositories / separate CI builds (like conda-forge)

  • Would require building infrastructure to deploy packages back together

  • Need to investigate how conda-forge does this

• Handle advanced versioning (a la conda)

  • Currently, there is only ever one version of a package available to the user at a given time. This is like a traditional Linux distro a la Debian. There are a lot of use cases where the user needs to mix and match versions specifically, which conda handles well.

• Support for non-Python dependencies

  • Currently, we've only run into things that emscripten already provides (freetype, libpng, libz), but we will need a way to handle others (e.g. Scipy needing OpenBLAS)

• Easy conversion of pure-Python packages to pyodide packages

  • From a local install, PyPI, tarball or git URL...

• Easier conversion of conda-forge packages to pyodide packages

  • Download a meta.yaml, clean up / tweak it if necessary

• Could pip install (for pure Python) be made to work at runtime? Probably not directly from the existing pip codebase.