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

[Yaroslav Halchenko]

On Tue, 28 Jan 2014, Alex Waite wrote:

> >>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).

> Is there a Debian policy against shipping the symlink? That's been
> my approach.

nope.. actually may be I took it wrong and symlink (if under non-/etc)
might indeed be the easiest way.


> >>>   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 ;)

> I think the version of support should vary from project to project,
> as it seems each projects assigns it's own level of meaning (or lack
> thereof) to version numbers.

yeah, ok - concur


> >>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...

> I would tend to agree. I was just throwing it out there.

;-)

> >>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 ;-)

> Perfect.

> >>>    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

> So, I found another option. Simply depend on the module in question,
> then setenv over the variable in question:

> `module load use.own`

> in ~/privatemodules/alex_freesurfer

> #%Module#
> module load freesurfer

> setenv          SUBJECTS_DIR            $env(HOME)/subj
> setenv          LOCAL_DIR               $env(FREESURFER_HOME)/alex_local
> ## EOB

> `module load alex_freesurfer`

sounds good!

> >Thank you Alex for looking into it!

> Not a problem.

> >may be now I will find
> >time to finish my ants updated package and will ship it with
> >modulesfile.

> Ooh. That'd be nice. Once I have some spare time, I'm going to look
> into the way we (internally) ship matlab and if there's any
> improvement to be made to the neurodebian matlab-support package
> (especially as it relates to envmod).

at the moment matlab-support indeed pretty much implements modules
system as well, but in "Debian way" through alternatives.  We might need
to find a closure on where we draw a line between the two ;-)

-- 
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