Thanks to Jupyter Server 2's IdentityProvider and Authorizer APIs, JupyterHub can almost go without monkeypatching, and implement all of its features via public APIs. However, one JupyterHub feature: disable_user_config is actually harder to implement with the extension mechanism, because it needs to modify the config and template paths of all other extensions. Most, if not all, of these are produced from jupyter_path or jupyter_config_path, and don't inherit from their parent ServerApp. I've resorted to the far-from-ideal patch of the __code__ attribute of the jupyter_core.paths functions to achieve the necessary goal, which was once achieved by a simple subclass override of NotebookApp.
But jupyter_path and jupyter_config_path unconditionally add user paths to their return.
If there were a public option to exclude user paths (ideally an env or module constant like site.ENABLE_USER_SITE so it's a process-global state, not per-call), I think I could achieve this purely via public APIs and remove the last major monkeypatch from jupyterhub.singleuser.
It's a pretty JupyterHub-specific feature, but because the logic resides in jupyter-core and it's unconditional and un-overrideable, I think that's the only way it can be achieved in a public-api way. What do folks think about a jupyter_core.paths.ENABLE_USER_PATHS flag?
blink1073
commented
1 year ago
Thanks to Jupyter Server 2's IdentityProvider and Authorizer APIs, JupyterHub can almost go without monkeypatching, and implement all of its features via public APIs. However, one JupyterHub feature:
disable_user_configis actually harder to implement with the extension mechanism, because it needs to modify the config and template paths of all other extensions. Most, if not all, of these are produced fromjupyter_pathorjupyter_config_path, and don't inherit from their parent ServerApp. I've resorted to the far-from-ideal patch of the__code__attribute of thejupyter_core.pathsfunctions to achieve the necessary goal, which was once achieved by a simple subclass override of NotebookApp.But
jupyter_pathandjupyter_config_pathunconditionally add user paths to their return.If there were a public option to exclude user paths (ideally an env or module constant like
site.ENABLE_USER_SITEso it's a process-global state, not per-call), I think I could achieve this purely via public APIs and remove the last major monkeypatch from jupyterhub.singleuser.It's a pretty JupyterHub-specific feature, but because the logic resides in jupyter-core and it's unconditional and un-overrideable, I think that's the only way it can be achieved in a public-api way. What do folks think about a
jupyter_core.paths.ENABLE_USER_PATHSflag?