[Neurodebian-devel] [RFC] Should we convert to use 'Modules' (http://modules.sourceforge.net/)?

[Yaroslav Halchenko]

On Tue, 28 Jan 2014, Alex Waite wrote:
> As a result of reading this RFC, I was inspired to convert our
> internal Freesurfer (5.1 and 5.3) packages to environment modules
> (envmod). 

ha -- are you implying that you guys hiding some work from the rest of
the folks? ;-)

> I'm still new to the framework, but here are my (early)
> thoughts.


> On 12/12/2013 05:30 PM, Yaroslav Halchenko wrote:
> > [snip]
> > [Modules] is being used on many systems, especially in HPC setups

> It looks like everyone with a serious HPC is using this. The
> SetUpFreeSurfer and FreeSurferEnv scripts are such a tangled mess
> that I ended up contacting two different HPC IT groups for their
> Freesurfer modfiles -- as a starting point. Both responded within a
> day with the files. From this experience alone, I perceive there to
> be good potential support out there.

great!

> > [snip]
> >I was thinking that we should start use 'modules' in place of our ad-hoc
> >shell (primarily bash) scripts.

> The sooner these scripts die, the better IMO.

;-) +1

> >[snip]
> > I have already
> >built backports for all releases (only not for ubuntu 10.04
> > [snip]

> Was it problematic to build on 10.04 or was it because it's EOLed?

somewhat both:  I just did a lazy nd_build4allnd, on 10.04 elderly
debhelper and 32bit has been failing for a while anyways because of way
too big harddrive for it to handle ;-)

> In my experience, 10.04 was the last sane release by the Ubuntu
> folks and I wouldn't be surprised if it become the Windows XP of the
> Ubuntu world. 

oh no -- yet another system with lack of proper security updates?

> Do we have stats on what percentage of Neurodebian
> users are on 10.04?

we could get it, but I haven't compiled any stats recently... if you
compose a scriptie to operate on apache logs I could run against all we
have (if Michael also pushes fresh ones)... From a limited sample of
popcon voluntary submissions we see
http://neuro.debian.net/popularity.html#popularity-contest (just select
1.48 version of popcon) that it is declining but indeed quite large - 68
submissions out of 660 so under 10%.  Looking forward I would not bother
about it too much for various perspectives (way too many pieces to
not build or lack dependencies now)

> >a. within a package for tool X ship following files under
> >    /usr/share/modules/modulefiles/ directory:

> >   1.
> >    X/UVERSION

> This is sane and seems to be the standard.

> >   2.
> >    X/.version

> >    file specifying the default version (similar to our current
> >    /etc/fsl/fsl.sh -> 5.0/fsl.sh)

> From what I've read, the X/default file is looked for first, then
> X/.version. The default file can merely be a symlink to the default
> version modfile while the .version file is a two line file setting
> the default version number.

> In my opinion, it's slightly easier, more intuitive, and less error
> prone to go the default symlink route rather than the .version file
> --- especially if we ever have a need to modify it via a postinst
> script. However, both are so dead easy that I don't have a strong
> preference.

well -- .version is easier to control from the 'package' -- just
shipping it.  symlinks are trickier imho (as you noted -- postinst and
possibly other magic would be needed). 

> >   3.
> >    For packages for which we maintain multiple major releases (e.g. FSL 4.1 and
> >    5.0), provide symlinks to the supported release line (similar to dynamic
> >    libraries setup). e.g. if for ants we decided to support both old 1.9
> >    and new 2.0: 2.0 -> 2.0.0,   1.9 -> 1.9.8

> >    this way users could explicitly load a specific 'release line', e.g.

> >     module load ants/1.9 (or module load fsl/5.0)

> Isn't this what point 1 is already doing? The only thing I see
> different is having a link from fsl/5.1 to fsl/5.1.1. But I don't
> see the point of doing that unless we plan to have both fsl 5.1.0
> and fsl 5.1.1 installed at the same time (which I don't think you're
> suggesting). I think we can just keep it as fsl/5.1 for all bugfix
> releases of fsl 5.1.

rright -- so we could strip epoch index from the version in
module... but I thought to consider it more generally -- may be we will
have multiple minor revisions as well (I believe fis-gtm folks might
needed it)... so indeed it could vary from pkg to pkg and we could
provide version at the level we support (in our case major.minor) but
then we get to -- major vs major (fsl 3 vs 4 vs 5) -- should that be our
level for fsl? for freesurfer major.minor (5.2 vs 5.3), ants --
undecided yet ;)

> >b. administrators would be welcome to add custom modulefiles
> >    pointing to local installations, happen they have them, and place them under

> >     /etc/environment-modules/modules

> >    By doing so they might 'overload' definition of the default
> >    version specified in /usr/share/modules/modulefiles/X/.version thus it
> >    would be up to them either symlink that .version file or just have
> >    their possibly newer version being default

> This makes sense. An additional option is to allow the admin to
> select the default version via a dialog at install.

hm, not sure if we would want to complicate our lives that much...

> >c. we then could replace custom /etc/X/X.sh scripts with simple 'module load X'
> >    (versioned or not), to avoid any duplication of the setup while staying compatible
> >    with existing deployments.

> Yes, this should work. Do other versions have to be explicitly
> unloaded first, or is that taken care of automatically by envmod?

I believe that is the point of modules to take care about unloading prev
versions ;-)

> >    The only catch here which I do not know how to resolve yet
> >    without interaction with users is:

> >    $> tail -n 3 /etc/fsl/fsl.sh /etc/afni/afni.sh
> >     ==> /etc/fsl/fsl.sh <==
> >     if [ -f "${HOME}/.fslconf/fsl.sh" ] ; then
> >       . "${HOME}/.fslconf/fsl.sh" ;
> >     fi

> >     ==> /etc/afni/afni.sh <==
> >     if [ -f "${HOME}/.config/AFNI/afni.sh" ] ; then
> >       . "${HOME}/.config/AFNI/afni.sh" ;
> >     fi

> >    Since these are shell-specific they can't be just "sourced" anyhow within
> >    modulefile.  It should be possible to check and warn users though if such a
> >    file was found present, and advise to convert it to modulefiles but I am not
> >    yet sure on how easy that would be todo/enable.

> The envmod website does mention the env2 project
> (http://sourceforge.net/projects/env2/) which helps convert
> environment variables across shell languages. It could be a start.

Thanks! I will check it out as well

> >    There can be ~/.modulerc file providing generic tune up, e.g.

> >     $> cat ~/.modulerc
> >     #%Module1.0#######################################################################
> >     module-version ants/1.9 default

> >    would specify that I want to use 1.9 regardless of the system-wide
> >    defaults.  Thus question:

> >    Q: How we could enable per user per module specific settings?
> >    If someone had experience with Modules -- I would be great full for
> >    your help.

> I think this is what `module load use.own` is for. Though I am not
> sure if it as as simple as appending/overwriting a single variable.
> I think the entire modfile needs to be duplicated, though I am not
> certain.

good catch -- indeed worth checking

> Thanks for finding envmod. It looks to be far superior to the
> current method.

the least I could do ;)  it is indeed used all over on HPC and thanks to
Alastair -- packaged for Debian.  so -- I just got familiarized and only
just a bit.  Thank you Alex for looking into it!  may be now I will find
time to finish my ants updated package and will ship it with
modulesfile.

-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate,     Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik