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.
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.
It is also possible to do it in Jupyverse: just create a plugin with a FastAPI startup event.
@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?
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.