Set JPY_SESSION_NAME to the notebook path (same as jupyer_server does)

[nocnokneo]

References

• Document JPY_SESSION_NAME environment variable, which contains current notebook's file path jupyterlab/jupyterlab#16282

Code changes

Set JPY_SESSION_NAME to the notebook path, same as jupyer_server does. This ensures that notebooks that use this feature in Jupyter Lab continue to work when served by voila.

User-facing changes

• None

Backwards-incompatible changes

• None

[github-actions]

👈 Launch a Binder on branch nocnokneo/voila/set_jpy_session_name

[trungleduc]

Thanks for working on it. Could you verify if the exposed path is a relative path to the current voila directory or the absolute path to the notebook?

[nocnokneo]

Thanks for working on it. Could you verify if the exposed path is a relative path to the current voila directory or the absolute path to the notebook?

Reworked this to actually work :-) Now returns the absolute OS path to the notebook. Tested with invocations like voila and voila notebooks/notebook_path.ipynb

[nocnokneo]

Any additional changes you'd like to see?

[trungleduc]

Hey, sorry for the late reply. I don't feel comfortable with exposing the full file path to the frontend. In JupyterLab, you have access to the server file system via the terminal or by executing Python code, so there is no point in hiding the file path. But Voila environment is more restrained, and exposing a relative path is enough.

What do you think @jtpio @martinRenou?

[nocnokneo]

Sorry, I realized that I forgot to provide a use case which might help give more context:

I'm using pixi-kernel to JIT-provision the notebook's environment. This depends on accessing the notebook's metadata to get the name of the Pixi environment that should be provisioned. I can imagine other solutions, but in general it seems preferable to minimize the number of special cases that users need to address when running a notebook with Voila that already works with other servers like Jupyter Lab.

[nocnokneo]

Hi @trungleduc @jtpio @martinRenou Just checking in to see if there have been any more thoughts or internal discussion on this topic?

[jtpio]

I don't feel comfortable with exposing the full file path to the frontend

Similar feeling at first, without checking if it would be real security issue.

Otherwise, have you tried to use a pre_launch_hook? https://voila.readthedocs.io/en/stable/customize.html#creating-a-hook-function

The docs mention:

The second argument will be the NotebookNode, which you can mutate to e.g. inject cells or make other notebook-level modifications.

Maybe your Pixi provisioner would be able to use the information the pre_launch_hook would make available?

[nocnokneo]

Similar feeling at first, without checking if it would be real security issue.

I agree that the security implications are important to consider, but I think there's simple way to look at this. From the security model perspective, keeping the notebook path information secret is hard to do so building a policy that assumes path secrecy creates a brittle contract: one debugging log message or third‑party extension can blow the guarantee. Voila’s existing model of "no code execution, no arbitrary file access" is a cleaner, testable boundary. Not wanting to add the notebook path to an environment variable feels like taking a "security through obscurity" approach.

Maybe your Pixi provisioner would be able to use the information the pre_launch_hook would make available?

I considered that initially, but it doesn't work with pre-heated kernerls which we plan to use soon. Open to suggestions here, but still feel like having Voila aligned out-of-the-box with the precedent set by Jupyter Server and JupyterLab maximizes portability, simplifies the ecosystem, and keeps security boundaries clear and enforceable.

Thanks for considering — happy to elaborate or help with a documentation note if that would move the PR forward.

[nocnokneo]

@trungleduc @jtpio @martinRenou Friendly ping