search

nesi / rstudio_on_nesi

RStudio server on jupyter.nesi.org.nz
4 stars 1 forks source link

Allow selection of R-Version #2

Closed CallumWalley closed 2 years ago

CallumWalley commented 3 years ago

Currently version of R used is whatever is the default lmod version. Version set here: https://github.com/nesi/rstudio_on_nesi/blob/1d58919b6be5efd179035f003f4607dd37778359/conf/r_nesi_centos7.def#L68

$RVER is currently not set anywhere (but could be).

Best way to allow customisation (in my opinion) would be through the use of a flag during setup. e.g. --module=R/2020a or whatever (when using pip, it would take the form -install-option="--module=R/4.1")

Problem is I don't know how to pass that information from setup.py to rstudio_on_nesi/__init__ or rstudio_on_nesi/singularity_wrapper.sh where it is needed when launching (e.g. setting $RVER).

I imagine you could do this by setting package metadata, or by writing a file in package install location, but I don't know how to do either of these things.

Other considerations

Could you put multiple entry points under the jupyter_serverproxy_servers dict in setup.py, one for each version of R we want to support? Then we would have a different launcher button for each one (e.g. "Rstudio with R 3.6", "RStudio with R 4.0", etc)

CallumWalley commented 3 years ago

@jennan @chrisdjscott Appreciate any ideas. Chris' idea would be simple to implement, but could be a bit restrictive (or spammy).

chrisdjscott commented 3 years ago

Best way to allow customisation (in my opinion) would be through the use of a flag during setup. e.g. --module=R/2020a or whatever (when using pip, it would take the form -install-option="--module=R/4.1")

Does that mean you expect the researcher to run the setup.py install themselves and pick and R version? I was thinking we would install it into the JupyterLab module so it's just there for everyone (who has created the password file), rather than making each researcher do it, and they can easily switch between R versions if they want to. Can you elaborate on how it would be restrictive/spammy?

CallumWalley commented 3 years ago

If I am understanding correctly, we would need to make an entry point for each different R-module we could expect people to want (and would have to update with new releases of R), that would lead to quite a lot of launchers.

CallumWalley commented 3 years ago

I was thinking we would install it into the JupyterLab module so it's just there for everyone

Definitely, for this one though we could not set Rversion (and therefore loads whatever the current default R module is). If a researcher wants a different version of R they can install it.

jennan commented 3 years ago

At the moment, we already pre-populate the jupyter launcher with 4 R-related kernels (3.6.1, 4.01, 4.1.0, and a weird R Spectre test... but maybe this one is just me having installed something). If we do this for the R-kernels, why not the rstudio launchers (for consistency)?

Side note: if it exists an option to group launchers or hide them but not from a drop down menu that could solve our issue, as we would not need to be shy adding many kernels by default.

jennan commented 3 years ago

This extension https://github.com/jupyterlab-contrib/jlab-enhanced-launcher could address the issue of providing too many kernels to the user (there is a search and list mode).

CallumWalley commented 3 years ago

Ok, so what versions do we need. I know @DininduSenanayake wanted "R-bundle-Bioconductor", there is also R-geo. I would still like to be able to customise version at install, but i'll add the extra entry-points for now.

jennan commented 3 years ago

Oh I see... sorry I was only thinking about R versions, not all combinations of R versions + modules. Would it be OK to create big bundles (R + major NeSI modules) instead?

DininduSenanayake commented 3 years ago

Yeah..R-bundle-Bioconductor and R-Geo are the main bundles (don't worry about R-Spectre. Not sure why everyone has it as I am quite sure it's only one researcher using it) R-Geo is something we do not provide as it is built on top GEOS (UDUNITS+GDAL) module which is a dependency for number of geo spatial R packages

chrisdjscott commented 3 years ago

Is there any conflict between R-Geo and R-bundle-Bioconductor (i.e. any reason they can't be loaded at the same time)? I was assuming we could have one launcher entry per R version (3 total by the looks of it) and load the other modules within it, like we do with the kernels (e.g. https://github.com/nesi/mahuika-jupyter-kernels/blob/master/bin/ir410-gimkl-2020a.sh).

chrisdjscott commented 3 years ago

R-spectre is just there for nesi99999, I added it for Matt to test and guess he's finished by now so could remove it again.

jennan commented 2 years ago

Versions 0.22+ allow user to create a prelude.bash script to preload modules (inclusing R-Geo and R-bundle-Bioconductor) and use their interpreter within rstudio.