Question about porting a v1 jupyter plugin: Our v1 plugin had to set

os.environ[PYTHONPATH] = ":".join(sys.path)

before running the notebook via

jupyter_core.command.main()

. Is this still appropriate to do in v2 or is there a better way. This was needed so the spawned kernel could inherit the path of the targets.

Very similar for setting pythonpath. You’ll set

PEX_EXTRA_SYS_PATH

to the source roots being used, like

src/python

. Pex uses this to extend PYTHONPATH See https://github.com/pantsbuild/pants/blob/ff02ef0ddd284bc5f4d9d4a724c3d8ecbe066854/src/python/pants/backend/python/goals/repl.py#L44-L48 for how that’s done with the normal Python repl

Hmm... If I use the chroot, then the Notebook file will get saved in a hidden directory. I want the Jupyter Notebook app to have the top of the repo as its root. Or maybe the

dist/

directory. That way it is easier for the eng to work with the file after they are done with the notebook.

If I am using the “Pex: Install binaries through pip” way of getting my jupyter binary

The

PEX_EXTRA_SYS_PATH

is only needed when you run the process, not when building the Pex. It gets used at runtime, and isn’t necessary when building the Pex

Got it. Thank you for the orientation. 🧭

then the Notebook file will get saved in a hidden directory

Oh, hm, interesting. How does saving the notebook file work? Jupyter will write the file for you? Can you specify where that file gets written?

Jupyter Notebook opens by default to the directory that you run the command

jupyter notebook

from. You can add the

--notebook-dir=/path/somewhere

option to set the root to where ever you wish. Once started, the Jupyter Notebook app can't read or write above that directory. The kernel has access to all the paths that were set when it was spawned (I believe).

@hundreds-breakfast-49010 what’s the story around an

InteractiveProcess

running in the build root, with it writing to arbitrary file paths in the build root? Pants has no restrictions on that, right? This is why we solely allow a

@goal_rule

to run an

InteractiveProcess

, which acts ~like a lock

layers upon layers upon layers

yeah, an interactive process is run using the rust std library API for spawning a subprocess, and that subprocess can do arbitrary things

Since the kernel is getting the target from the chroot, then changes to the repo won't impact a running kernel, correct? This is actually a small pain point in that engineers have to quit and restart notebooks when they change python libraries. 🤷🏽‍♀️

That’s correct that it will not restart the notebook if the code changes. It will continue using the chroot’s code, rather than the repo’s changed code, afaict. Is that the behavior you want?

I don't think we want that at this point.