Hi, I can give our perspective at UPPMAX in Uppsala, Sweden, which as thus far been outside of EB, but uses Lmod.
Our centre includes a bioinformatics-oriented sensitive-data cluster with no internet access. Users can bring tarballs etc. in, but because of the nature of the cluster, that is intentionally multistep process. User installations of language packages are difficult under these conditions for the average user. Some package managers have a "download only" option that can effectively handle cascading dependencies, but then continuing that process and installing from the tarballs presents difficulties as well for the average user, and there is often something missed along the way. As a result, for a couple years now we have been providing "omnibus" modules. - for R, we have a single R_packages module that contains installations of everything possible from CRAN and BioConductor, tied to a particular R version. There are also some R packages included that are not on CRAN or BioConductor, as requested by users or required by other modules. We also use this module internally; if another module requires specific R packages, we almost always load this module. - for Perl, we provide a "many packages" module in Perl containing common prereqs for other modules but also common user-level packages, also tied to a particular Perl version. We don't attempt to be complete with respect to CPAN, but do make frequent use of this module internally. - for conda, we provide a module that is as complete a download-only mirror of conda as is possible The R_packages and conda modules in particular are heavily used on the sensitive-data system. The R_packages module also gets a lot of use on our other clusters. conda is always a bit of a headache without internet access, so on clusters with internet access conda is used directly, without that module. We don't update packages within a specific R_packages module unless there is a killer bug. We save those for the R_packages module that accompanies the next version of R. Here's a readme for our R_packages/3.6.1 installation. https://github.com/UPPMAX/install-methods/blob/master/apps/R_packages/R_packages-3.6.1-install-README.md Best, Douglas — Douglas G. Scofield Evolutionary Biology Centre, Uppsala University douglas.scofi...@ebc.uu.se<mailto:douglas.scofi...@ebc.uu.se> douglasgscofi...@gmail.com On 2019 Nov14, at 09:24, Loris Bennett <loris.benn...@fu-berlin.de<mailto:loris.benn...@fu-berlin.de>> wrote: Hi, Looking at RStan, I'm wondering what the current thinking is with regard to extra R packages. Inspired by John Dey's approach, e.g. https://github.com/FredHutch/easybuild-life-sciences/blob/master/fh_easyconfigs/r/R/R-3.6.1-foss-2016b-fh1.eb I currently have a local 'R extras' easyconfig, which at the moment just contains the packages needed for RStan plus one other package. However, separate easyconfigs for RStan exist: $ eb -S RStan CFGS1=/trinity/shared/easybuild/software/EasyBuild/4.0.1/easybuild/easyconfigs/r/RStan * $CFGS1/RStan-2.18.2-foss-2017b-R-3.4.3.eb * $CFGS1/RStan-2.18.2-foss-2018b-R-3.5.1.eb * $CFGS1/RStan-2.18.2-intel-2017b-R-3.4.3.eb In addition, I need to build RStan with the following extra compiler flag: CXXFLAGS += -DSTAN_THREADS Whilst this example would probably not cause any problems in a large 'R extras' easyconfig, there could be conflicts if the macro names are more generic. So is the best approach all packages in a single bundle except for those which need some special tweaking? Cheers, Loris -- Dr. Loris Bennett (Mr.) ZEDAT, Freie Universität Berlin Email loris.benn...@fu-berlin.de<mailto:loris.benn...@fu-berlin.de> När du har kontakt med oss på Uppsala universitet med e-post så innebär det att vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/ E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/en/about-uu/data-protection-policy
