PEP 752: Package repository namespaces

Thanks @ofek for reaching out to Jupyter! Speaking on my own here, not on behalf of the project or anything.

I think this is really interesting, and a good idea. I don’t personally have a strong opinion, but there may be a slight preference in parts of in our community for npm-style, largely because our projects often straddle npm and PyPI, and we and our users (extension authors, at least) are already used to @jupyterlab/pkg, and coming from GitHub, the meaning of @owner/pkg is clear for many, if not all. But I definitely see the strong backward-compatibility arguments of the prefix approach.

Any transition will be tricky for us because the existing widespread use of prefixes (jupyter-, jupyterlab-, ipython-, and jupyterhub-) is very much used by both official projects and community plugin packages, alike. This has been a communication issue, in that it is unclear from package names alone, what projects are ‘official’. I don’t have numbers, but I think unofficial plugin packages outnumber official ones significantly with these prefixes (at least on jupyterlab-, the most plugged-into part of the project). The current proposal would not change that, but it would at least stop the unofficial population of the plugin namespace from growing.

Since the maximize backward-compatibility strategy (which I love) means all those packages get to stay, we would have the choice:

  • keep current prefixes, in which case most packages on our reserved prefix are unofficial, so the prefix itself is not meaningful (as is the case today). New plugins would need to pick different names, while existing ones would keep the privilege of occupying the official namespace indefinitely. The main problem solved by this is typo squatting, I think.
  • pick a new (less obvious) prefix, like jupyter-official, meaning we have to rename all of our packages, but the name would be strictly meaningful.
  • leave jupyterlab- namespace unreserved (status quo), but reserve others, e.g. jupyter-

A case could be made that we shouldn’t actually be able to reserve jupyterlab- when we already don’t control a majority of the packages in it.

I’m not sure what we would choose. I don’t think we would pick moving to a new only-official prefix unless it was @npm-style. I’m not 100% sure we would do that, given the user impact.

10 Likes