Depending on jupyter-server-proxy
betatim opened this issue · comments
Have you thought about depending on https://github.com/jupyterhub/jupyter-server-proxy as an alternative to having to copy and paste the code from it?
Was wondering if something needs to change in jupyter-server-rpoxy to make that possible and other thoughts on this.
One advantage would be that jhsingle-native-proxy gets all the improvements and bug fixes "automatically".
My main objection to using jupyter-server-proxy directly was its dependency on notebook. It is ideologically cleaner not to have that installed when the point of jhsingle-native-proxy is to cut out the notebook-related bits, including all the etc/jupyter and share/jupyter data files in setup.py.
In an ideal world, maybe jupyter-server-proxy would incorporate the jhsingle-native-proxy functionality so everything is maintained in one repo. setup.py could have a [native] install option that misses out the notebook stuff. Or instead perhaps a shared package for the core proxying behavior could be used by both downstream packages.
But I think there are some fundamental differences between the two that would make this code more complicated for everyone:
jupyter-server-proxy has proxy classes based on notebook.base.handlers.IPythonHandler, whereas jhsingle-native-proxy is based on jupyterhub.services.auth.HubOAuthenticated:
ProxyHandler(WebSocketHandlerMixin, IPythonHandler) versus ProxyHandler(HubOAuthenticated, WebSocketHandlerMixin) - the inheritance order is different here for a start; not sure if that has any other side-effects!
Other than those fundamentals, jhsingle-native-proxy has to implement alternative forms of tornado.web.authenticated to account for the 'authtype=none' option introduced to cope with BinderHub only having ?token query GET parameter as a form of authentication. (This could probably be simplified internally in jhsingle-native-proxy in any case, e.g. by overriding current_user with a dummy.)
So I think the dependencies are the main blocking point, and then the next concern is complicating code - the proxy classes are going to have to be parameterised in terms of base classes, so we end up with some kind of factory.
In terms of simplifying the dependency tree, it might actually make more sense for jupyter-server-proxy to depend on code in jhsingle-native-proxy instead. Then the objection could be the dependency on jupyterhub. I have seen it suggested elsewhere that the only real requirement, jupyterhub.services.auth, would make sense to be isolated from the rest of JupyterHub anyway.
Happy to collaborate on this if it is important to anyone!
I didn't particularly mean to close this issue!
I hadn't thought of the dependency on notebook. Not having that is the whole point of having this standalone proxy. So it seems like it would be quite a bit of effort/unclear how to do this without complex inheritance/factory patterns/etc.
Yes, I think so. Closing again for now, but happy to revisit if anyone wants to.