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

[Alex Waite]

On 01/28/2014 05:35 PM, Yaroslav Halchenko wrote:
>
> 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? ;-)

Hah. You wish. No, this is the dirtiest, least elegant way of deploying 
Freesurfer. No compiling, just getting their binary and dumping it into 
a dir.

>> Do we have stats on what percentage of Neurodebian
>> users are on 10.04?
> [snip]
> it is declining but indeed quite large - 68
> submissions out of 660 so under 10%.

Yeah, that number will only drop more. Given the problem with building, 
I agree it's not worth it.

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

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

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

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

---Alex