Transitioning server extensions to the conf.d approach

[jasongrout]

(This issue is mainly about documenting an issue with jupyter serverextension, and mentioning a workaround for a problem transitioning to the current best practices)

With nbextensions, we can do jupyter nbextension uninstall <extension> in order to remove a reference in the notebook config file to an extension. We can't do the same for server extensions, we can only explicitly enable or disable them, either way leaving an entry in the notebook config file.

This is a problem when doing automated enabling/disabling at install/uninstall time. We've been enabling on install, disabling on uninstall, for example in the jupyterlab conda-forge package: https://github.com/conda-forge/jupyterlab-feedstock/blob/master/recipe/pre-unlink.sh.

The better way to do automatic enabling is to use the conf.d approach available in the notebook now. However, we now have a problem transitioning a package to the conf.d approach, since there is no way to remove the notebook config entry we've already put in there.

A somewhat kludgy way for us to move forward is to release several JupyterLab upgrades with no pre-unlink scripts, so that most users will just have jupyterlab explicitly enabled without a disabling step on uninstall. Then remove the automatic enable step, and most users will continue to have a harmless enable entry in their notebook config.

I think it's better if we can explicitly remove this entry using a jupyter serverextension uninstall command, similar to what we can do for nbextensions. However, the workaround suggested above is probably sufficient for the vast majority of users.

[jasongrout]

Closing, as I think we probably won't do anything about this, other than this documentation of a way to transition to the conf.d approach.