Make available for jupyterlab regardless of which kernel is used for a specific notebook

[joelostblom]

I just read https://blog.jupyter.org/inspector-jupyterlab-404cce3e1df6 and I am excited to see that this repo was revived last fall, thank you for working on it again! Currently it seems like I need to have docrepr installed in every virtual environment where I want to use it. I usually have a separate environment for my jupyterlab install and then use nb_conda_kernels to work with other environments. For this workflow it would be convenient if docrepr could just be installed once (in the jupyterlab env) and then work for jupyterlab launched from that env, regardless of which kernel a specific notebook is using. Would it be possible to implement this feature or is it relatively hard/time consuming?

[martinRenou]

Hey. I wonder if you could install it in your JupyterLab env and then extend the PYTHONPATH so that ipython is able to import the docrepr from that environment?

[ccordoba12]

Since the docstring processing is done kernel-side, I don't think that's possible unless you do hacks like the one mentioned by @martinRenou.

For this to work on the JupyterLab side, I think a server extension should be developed that uses docrepr. But then, the internal process would be totally different, i.e. IPython would only send the raw docstring and the extension would process it and pass it to Lab's inspector (I guess).

[CAM-Gerlach]

To note, I'm not sure there's anything we can do about it directly on the Docrepr end, as opposed to something on the JupyterLab side.

I imagine your users already need to install ipykernel, etc. in your working/client environments (or have it installed for them). Could you ensure docrepr was installed the same way, maybe with some meta-package that includes the optional kernel-side requirements for JupyterLab, sort of like Spyder-Kernels for Spyder (though the latter is more than a metapackage)?

Hey. I wonder if you could install it in your JupyterLab env and then extend the PYTHONPATH so that ipython is able to import the docrepr from that environment?

The prospect of less experienced users hacking PYTHONPATH as opposed to modern, standardized packaging methods sends cold shivers down my spine...surely there must be a better way?

But then, the internal process would be totally different, i.e. IPython would only send the raw docstring and the extension would process it and pass it to Lab's inspector (I guess).

And at least for full operation, docrepr needs not just the docstring, but a bunch of info about the object as well. You either need to gather that kernel-side, or serialize the whole object.

@ccordoba12 how do we currently do it in Spyder for our own help viewer in Console mode? Does the code run kernel-side, or do we serialize the objects with cloudpickle and then extract the info Spyder-side?

BTW, @martinRenou thanks for the nice acknowledgement in the blog post! Would you mind linking to my GitHub instead of some old Twitter that I almost never use? (I also have my Gerlach.CAM website, but I need to get the DNS working again, heh)

[martinRenou]

BTW, @martinRenou thanks for the nice acknowledgement in the blog post! Would you mind linking to my GitHub instead of some old Twitter that I almost never use? (I also have my Gerlach.CAM website, but I need to get the DNS working again, heh)

Sure :)! Doing it now

[ccordoba12]

@ccordoba12 how do we currently do it in Spyder for our own help viewer in Console mode? Does the code run kernel-side, or do we serialize the objects with cloudpickle and then extract the info Spyder-side?

We ask the kernel for the object's docstring (using the inspect module, I think) and then pass it to our internal version of docrepr. Then the result that comes back from it is sent to our Help pane.

That's what, in my humble opinion, a server extension for JupyterLab should do too.