-
Notifications
You must be signed in to change notification settings - Fork 5.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pex compatibility for ipykernel launch #2636
Comments
at least one semi-reasonable strategy here that I can see would be to compose a shim/surrogate entrypoint that wraps the notebook launcher in the pex context that would:
this helps isolate the configuration to a per-run instance vs stashing keyed, per-run copies in e.g. I'm planning to run with this model now for the purposes of experimentation, but open to better strategies here if anyone has ideas. |
If I interpret this line in If your kernel specs do set some environment variables, you could customize the launcher to pass selected environment variables from the notebook server to the kernels. Or you could customize the kernel manager to always pass an environment definition to the launcher. If you get the list of environment variables to be propagated from the configuration, you could create a PR and maybe get your changes merged. |
the env var that needs to be set would specify the entrypoint of the kernel launcher, so in terms of concerns it'd be part of the "kernel configuration" (i.e. something we set only at kernel launch time vs something we'd want as a static env var in the parent, which in theory could potentially leak into other non-desired contexts or kernel launches). tho it seems already possible to embed a static env var like this directly into a so afaict, to make this all first class it seems like jupyter would need a way to specify kernel configuration in a plugin type model (i.e. executable python code vs json). it might also be cool to use a registry/discovery type pattern against the installed plugins so that just e.g. their presence in the python environment could enable them for use. this would make it as easy as a fwiw, I've posted an initial implementation of the surrogate shim approach described above here which is working well for the moment. |
The KernelSpecManager and KernelManager classes are the implementations of finding and launching kernels, respectively. These are swappable for alternate implementations via the I just put together pexnb which provides a KernelSpecManager that works with PEX and tells the notebook server to use it by default. You should be able to build a notebook env with pex via:
It has the assumptions:
|
Quick reminder: I'm planning a revamp of the kernel finding machinery, described here: jupyter/jupyter_client#261 |
thanks for the pointers and reference implementation @minrk - very helpful! |
at Twitter, our data science and machine learning teams are attempting to package up Jupyter notebook as a self-contained pex for easier distribution and compatibility with our internal build and execution environments.
presently, attempting to create a new notebook while running jupyter notebook from a pex results in a failure to launch the kernel:
the key output here being:
which seems to indicate that jupyter is attempting to relaunch the equivalent of
python -m ipykernel_launcher ...
. this is confirmed by looking at the kernel.json forPython 2
:in the pex context, all transitive dependencies needed for execution are self contained within the pex as opposed to sourced from a traditional python environment (e.g. the interpreters
site-packages
or an outer venv). you can think of it kind of like a zipped executable virtualenv without any externalized environmental setup. so in the case of the attempted launch mode, the pex context will be lost leading to a failure to locate theipykernel_launcher
module in the base vanilla python interpreter's stdlib.so in order to properly launch an ipykernel from within a pex, we'd need to be self referential and set environment variables. from the CLI, that would look like something along the lines of:
FWICT, it seems like at least one way to accomplish this would be to overload/hijack the main notebook server entrypoint and spit out a custom "kernel spec" prior to server launch that would essentially look like:
however, it'd be great to avoid hacks like this in favor of a more first class support model for pex.
if anyone has any better solutions or a high level strategy on how to go about adding better first class support for pex in Jupyter, I'd be all ears - and more than willing to contribute the necessary PRs to realize that. thanks in advance!
The text was updated successfully, but these errors were encountered: