Hoist the Python package to the top-level?

[jtpio]

Problem

Currently the jupyterlite Python package is located under py/jupyterlite: https://github.com/jupyterlite/jupyterlite/tree/main/py/jupyterlite

If I recall correctly this was mostly to accommodate the potential new Python packages that would be developed in the monorepo such as #165.

Proposed Solution

With the use of CLI addons and support for federated extensions, maybe there won't be any needs for new Python packages in the same jupyterlite repository.

If we want to provide more Python packages, maybe they could live outside of the main repo but within the jupyterlite org on GitHub: https://github.com/jupyterlite

Benefits for hoisting the Python package to the top-level would be:

• a single pyproject.toml (the others in Pyolite will be moved to https://github.com/jupyterlite/pyodide-kernel with Move the Pyodide kernel to a separate repo #854)
• no need to sync the README.md
• follow the same structure as many other Jupyter projects

Additional context

In #854 and some other issues there were also mentions of having a jupyterlite_core or jupyterliter, and make jupyterlite a metapackage to distribute JupyterLite with a set of pre-defined packages.

Even if that was the case, maybe the jupyterlite metapackage could then also live outside in the main repo but still in https://github.com/jupyterlite.

[bollwyvl]

The labextension should be a wholly separate thing, for sure, but i do semi-lament use of [extras] for really anything, which means we'll have rather a lot of packages... and having them cut from the same tag of the repo really does feel better than setting up parallel structure (even if simple) on a bunch of repos, and having to coordinate releases.

same structure as many other Jupyter projects

Again, as with #881, as long whatever the buildchain is, it:

• generates reproducible tarballs
• can support building multiple packages
• is entirely installable from conda-forge packages
• doesn't break every time pip or packaging or whatever changes
• doesn't use the python packaging tool as the main CLI entrypoint, exposing only "do everything"
• doesn't create mountains of private, un-managed envs in magic places
• doesn't do any fancy nodejs stuff

So basically:

• treat whatever the python packaging tool is as just a node on the graph of things that need building
• don't get rid of doit

[jtpio]

Closing as we'll want to keep several Python packages in the same repo: #993