One of the attractive features of the IPython kernel is the ability to create rich output displays for objects using the
_repr_ display methods.
From the docs, I’m not sure how or where the decision is made about which output is rendered in any given display environment, or whether there is communication from the user environment that allows the kernel to modify it’s display behaviour. But there is a sense, for package designers at least, that they can define a range of rich output types and that something sensible will be rendered in the end user environment.
Another part of the kernels environment is the source file, such as a Jupyter notebook, from which the code is loaded. A recent Jupyter Enhancement Proposal – Transmit Cell Metadata – suggests “transmitting cell metadata to kernels”. This seems to provide code and package designers with some sort of awareness of the user environment in at least two possible ways:
- awareness of cell semantics or presentation semantics used for styling purposes, eg via tags;
- awareness of other environmental information stored as more general metadata; this might include information written to notebook metadata from extensions regarding presentation state, test cases associated with a cell, and so on.
In terms of the execution environment in a Python kernel,
import site;site.getsitepackages() can provide information about the home of packages, and
import sys; sys.path provides further path information (are there IPython introspection methods too regarding the current kernel?). Regarding the platform on which a kernel is running, package maintainers can identify the platform using
import sys; sys.platform. And I guess there are tools for detecting the presence or otherwise of GPUs? So code can have some awareness of its execution environment.
With the appearance of JupyterLite (JuptyerLab running in a browser against a WASM kernel), and JupyterLab-app (JupyterLab bundled with a Python kernel inside an electron app), as well as Thebe supported execution environments such as Jupyter Book, there are now multiple user environments that can render and execute code from the same source file.
In some cases, the actual user environment may afford or limit particular behaviours in terms of what can be rendered or presented to the user (for example, a console display may not support rich outputs); in other cases, the execution environment may be “bounded” (for example, a locally running kernel can make command line calls to the user’s home environment, a JupyterLite environment can’t).
So I wonder if it would be useful to have a means of communicating information from the (Jupyter) user environment to the kernel about the current user environment, or a simple set of “environment awareness” functions that can attempt to categorise or summarise the environmental context within which code is executing (this might include cell metadata, platform, user environment), at least at the IPython level?
It strikes me that if a user environment were to modify notebook metadata to identify the “current/last used” user environment, if the notebook metadata were also transmitted to the kernel, then the kernel could identify the user environment that way?