Shouldn't create non-hidden "privatemodules" dir in users home dir without asking

[adamltaylor]

Describe the bug

At least as installed by the Systems folks at my org, this package causes a "privatemodules" directory to be created in the users home directory on each login. This violates a longstanding guideline of how Unix/Linux applications should behave, namely that applications should never create non-hidden files/dirs in the user's home directory without asking permission first. If the dir was named ".privatemodules" (and thus was hidden), that would be fine.

I understand that in recent years, more and more applications have decided that it's ok for them to violate this guideline (possibly because they are unaware of the guideline), but I and many others still think it's a valuable guidline, and it would be nice if envmodules abided by it.

[xdelaruelle]

The ~/privatemodules directory is created when loading the provided example modulefiles named use.own. This is a legacy example modulefiles and nothing mandates to use it.

I will update this example to print a message when this directory is created. For next major release, I will update the modulefile to use a XDG-compliant directory location.

You mention that ~/privatemodules is created on each login. Could you precise which OS, distribution and version you are using. There is no need to load use.own module at login time. This may be an issue of either:

• the Modules package that have been installed
• specific configuration done on the global system or on your user account

Do you need help to determine where the use.own module is loaded at login time?

[linesr]

As part of loading the scheduler bits we also load a shared module location and then load the use.own so there is a consistent location across all users when accessing the HPC resource. I don't agree that changing the existing file given that it is the version that has been shipping for some time and making it use another location is a good idea. It would break existing users and particularly when a home directory is shared across multiple machines and OS versions resulting in inconsistent results when loading the same package provided module.

[adamltaylor]

For context: This is all within an HPC cluster. The login and worker nodes run Rocky Linux 9. @linesr is one of our HPC engineers. The ~/privatemodules dirs started spontaneously showing up in user's home dirs about a month ago.

[adamltaylor]

This is the use.own that seems to be in effect on one of the cluster login nodes:

<username@hostname>:/usr/share/Modules/modulefiles
$ more use.own 
#%Module1.0#####################################################################
##
## use.own modulefile
##
proc ModulesHelp { } {
    puts stderr "\tThis module file will add \$HOME/privatemodules to the"
    puts stderr "\tlist of directories that the module command will search"
    puts stderr "\tfor modules.  Place your own module files here."
    puts stderr "\tThis module, when loaded, will create this directory"
    puts stderr "\tif necessary."
}

module-whatis   "adds your own modulefiles directory to MODULEPATH"

eval set  [ array get env HOME ]
set ownmoddir   $HOME/privatemodules

# create directory if necessary
if {[module-info mode load]} {
    if { ! [ file exists $ownmoddir ] } {
        file mkdir $ownmoddir
        set null [open $ownmoddir/null w]
        puts $null "#%Module########################################################################"
        puts $null "##"
        puts $null "## null modulefile"
        puts $null "##"
        puts $null "proc ModulesHelp { } {"
        puts $null "    puts stderr \"\tThis module does absolutely nothing.\""
        puts $null "    puts stderr \"\tIt's meant simply as a place holder in your\""
        puts $null "    puts stderr \"\tdot file initialization.\""
        puts $null "}"
        puts $null ""
        puts $null "module-whatis   \"does absolutely nothing\""
    }
}

module use --append $ownmoddir

<username@hostname>:/usr/share/Modules/modulefiles
$ 

[xdelaruelle]

Thanks for provided details.

I don't agree that changing the existing file given that it is the version that has been shipping for some time and making it use another location is a good idea.

Such location change will happen for a major release (Modules 6.0) where everybody will need to analyze what all the breaking changes means for their systems. If you stay on Rocky Linux, it should not happen before version 11.

It would break existing users and particularly when a home directory is shared across multiple machines and OS versions resulting in inconsistent results when loading the same package provided module.

One strategy could be to take into account old fashioned directory if it exists but if not, only create in the new hidden location.

From my understanding, the main issue here is for the user to not be able to opt-out from use.own mechanism even if not needed.

What I suggest is to update the /etc/environment-modules/initrc configuration file and setup a personalized initialization by uncommenting the following code:

# restore user's default collection if it exists, otherwise load a predefined
# default module list
if {[is-saved default]} {
    module restore
} else {
    module load use.own
}

With such code, if a user has created a default collection, it is this collection that is restored rather than the default module list.

So @adamltaylor may save a default collection that does not contain the use.own, thus the ~/privatemodules directory will not be created anymore.

[adamltaylor]

@xdelaruelle Thank you for help---very much appreciated!