Relocate jupyterlab extension from @jupyterlab/server-proxy to @jupyterhub/jupyter-server-proxy

[consideRatio]

We are now in control of the @jupyterhub NPM organization, and I figure we should relocate our extension from the NPM organization/package @jupyterlab/server-proxy to @jupyterhub/jupyter-server-proxy.

I figure this change should be considered breaking, and ship with 4.0.0 if so.

Is there agreement to go for this? If so, I'll work it!

Related

• Rename jupyterlab extension id to match convention #323, closed as stale and insufficient
• jupyter-server-proxy lab extension cannot be disabled #322, resolved by documentation

[bollwyvl]

Yep, this is a fine, but also breaking, change.

[manics]

I don't have a preference which org it's in.
However if it's moved to the jupyterhub NPM org should we rename it jupyterlab-server-proxy? Are there any non-jupyterlab components in the NPM package?

[bollwyvl]

jupyterlab-server-proxy

🎉

[consideRatio]

Hmmmm hmmm oh you think so? This is a npm package tightly coupled to this python package so for me naming them differently doesnt seem right. It can (edit: can't i meant) be installed by itself, so should it really stand out with a unique name?

If something is to be renamed for consistency, i figure it would be the folder name in this repo, to labextension or similar.

[manics]

I don't think it's necessary to match package and repo names across different ecosystems- they're different ecosystems for a reason!

If a user discovers the jupyter-server-proxy Python package they don't need to care about the NPM package because everything's bundled in the Python package.

In contrast if they discover the package on NPM the name jupyter-server-proxy isn't an accurate description, since it's a jupyter-lab extension.

[bollwyvl]

Welp, it will work with Notebook 7, presumably, in a couple months. And indeed, there is sound precedent for jupyter-<whatever> for naming things that technically only work in lab... but folk generally don't bother publishing things that only work in classic, with current-gen widgets being one of the exceptions... and under the covers, those use a lot of lab tooling, such as lumino.

[manics]

Cool, I'll you two decide on the name 😃

[consideRatio]

Welp, it will work with Notebook 7, presumably, in a couple months.

I didnt understand what was "it" in the sentence above @bollwyvl, can you clarify?

Btw, i meant to say it can't be installed by itself. It must be bundled with the python package. So, due to that, it should connect to it very tightly in my mind.

[minrk]

I think there's (minor) benefit in the names matching, as they are developed as a single project. Also: not changing the name lets us not spend time figuring out a new name!

Happy with whatever folks working on it choose, and for it to be in the hub namespace.

[bollwyvl]

Looks like this blocks #366, so will go ahead and change to the name suggested in the title.

[bollwyvl]

#367

[bollwyvl]

Closed on #367, but have left the branch hanging around.