Jupyter server source script on launch

I’m trying to figure out if its possible to have jupyter server source a script when it is launched for a user similar to have everything in /etc/profile.d is sourced when a shell instance is initiated?

If this isn’t possible, is it possible to have Jupyterhub open a terminal as soon as its launched as sort of a default startup behavior?

The JupyterHub config file is actually a Python program; hence, if it’s something you can do with Python, like run a script, then you can do it from within the JupyterHub config file. I think the JupyterLab config file may work the same way.

There are also some hooks that can be configured in the config file that might be helpful.

2 Likes

Definitely possible. JupyterHub’s Spawner.cmd only requires that it eventually launches jupyterhub-singleuser (or one of a few equivalents like jupyter-labhub).

The standard way to do this, and one that I think gives a nice experience, is to create a launcher script like:

#!/bin/bash -l

# set any additional environment variables / do other startup

# finally, 'become' jupyterhub-singleuser
exec jupyterhub-singleuser "$@"

The bash -l starts a login shell, so it should be fully configured with profile, etc.

Then you set c.Spawner.cmd = "/path/to/that/script.sh" in your config, instead of the default jupyterhub-singleuser.

3 Likes

It is also possible to do it in Jupyverse: just create a plugin with a FastAPI startup event.

1 Like

@minrk This worked very well! We are able to generate variables in the login shell and dereference them in the .Renviron config. However, we are using jupyter-rsession-proxy to also use Rstudio within jupyterhub and Rstudio is not able to pick up on the variables generated during login. Any ideas for how we could achieve this?

1 Like

What environment variables are you setting? You might be running afoul of rsession proxy’s own environment setup: jupyter-rsession-proxy/__init__.py at 048f47a5251c7411227762f4f3ed71ca51dc49b0 · jupyterhub/jupyter-rsession-proxy · GitHub

We tested this on a variable completely unrelated to R. R Console was able to pick up on it, while Rstudio was not.

I wonder if rstudio itself is resetting the env? That seems odd, but maybe makes sense depending on how they deal with users.