"module use" does not conform with manpage

[xdelaruelle]

According to the "module" manpage, the "module use" command should behave as follows:

use directory [directory...]
use [-a|--append] directory [directory...]
  Prepend directory to the  MODULEPATH  environment
  variable.   The  --append  flag  will  append the
  directory to MODULEPATH.

However, what actually happens depends on the initial contents of MODULEPATH. For example:

$ module use /tmp
$ module use /home
$ echo $MODULEPATH
/home:/tmp
$ module use /tmp
/home:/tmp

So it appears that the search order in the MODULEPATH will not change if a specified directory is in the initial MODULEPATH. This applies to at least the following versions of modules - 3.2.6 & 3.2.7 (C-version) and 1.146 (TCL-version).

The actual behaviour of the "module use" could be considered a bug, because it does not conform with the manpage. This "bug" could be addressed in a few ways, such as:

1. Change the manpage to describe the actual behaviour.
2. Change the actual behaviour to match the manpage.
3. Avoid "module use" commands and set MODULEPATH directly.

I would prefer option 2 over option 1, because the current behaviour can cause confusing errors in scripts. For example, if a script inherits a MODULEPATH from the environment, the MODULEPATH may not be set as expected by an internal "module use" command. Option 3 avoids the problem, but it may not be future-proof.

Reported by: mw00ds

[xdelaruelle]

• status: open --> accepted
• assigned_to: R.K. Owen
• milestone: -->

Original comment by: rkowen

[xdelaruelle]

I will implement this in the 3.3.x line. I'm reluctant to change the 3.2.x line with this, since it changes a long standing "feature."

Original comment by: rkowen

[xdelaruelle]

The more I think about it the more I like option #1. Just modify the manpage so it says: --append will add the directory to the end of the MODULEPATH if the directory is not already in the path.

(Keep it simple) :)

Original comment by: sirdude

[xdelaruelle]

Option #2 is not really that difficult. Users can already work around the problem at the command-line by performing a 'module unuse' before each 'module use'. But it would be more convenient if 'modulecmd' did this automatically, so that users always get the MODULEPATH they expect.

I have a modified version of modules-3.2.6 that implements the change described above. Please see the attached patch.

Index: ModuleCmd_Use.c
===================================================================
--- ModuleCmd_Use.c (3.2.6)
+++ ModuleCmd_Use.c (3.2.6b)
@@ -188,12 +188,17 @@
     }

     /**
-     **  Remove is done by another subroutine
+     **  Always remove paths so they are replaced in the expected order.
+     **  Remove is done by another subroutine.
      **/
+    if( ModuleCmd_UnUse( interp, argc, argv) == TCL_ERROR) {
+      /* Command failed, so return error status */
+      return( TCL_ERROR);
+    } else if ( g_flags & M_REMOVE) {
+      /* Current mode flags specify that paths should only be removed */
+      return( TCL_OK);
+    }

-    if( g_flags & M_REMOVE) 
-   return( ModuleCmd_UnUse( interp, argc, argv));
-      
     /**
      **  Append or prepend the new module path
      **/

Original comment by: mw00ds

[xdelaruelle]

In reply to Milton Woods (mw00ds@users.sf.net):

To: "[modules:bugs] " 60@bugs.modules.p.re.sf.net
From: Milton Woods mw00ds@users.sf.net
Reply-To: "[modules:bugs] " 60@bugs.modules.p.re.sf.net
Subject: [modules:bugs] #60 "module use" does not conform with manpage
Date: Wed, 06 Mar 2013 23:43:55 +0000

I know it's not difficult. But really, I think the manpage does not
have enough information in it currently reguardless of what solution
is used. Example: say I have this:
/soft/rko-modules:/home/mein/.modules
If I do a module use /home/mein/.modules
should it do this or this? (assuming #2 is picked)
/home/mein/.modules:/soft/rko-modules:/home/mein/.modules
/home/mein/.modules:/soft/rko-modules
I also think that having the same dir used multiple times should just
warn you that you already have that dir in your path and not make any changes.

Kent

Option #2 is not really that difficult. Users can already work around the
problem at the command-line by performing a 'module unuse' before each
'module use'. But it would be more convenient if 'modulecmd' did this
automatically, so that users always get the MODULEPATH they expect.

I have a modified version of modules-3.2.6 that implements the change
described above. Please see the attached patch.

Attachment: modules-3.2.6b.diff (808 Bytes; application/octet-stream)

 ----------------------------------------------------------------------

[bugs:#60] "module use" does not conform with manpage

Status: accepted
Created: Thu Nov 15, 2012 03:29 AM UTC by Milton Woods
Last Updated: Wed Mar 06, 2013 05:19 PM UTC
Owner: R.K. Owen

According to the "module" manpage, the "module use" command should behave
as follows:

use directory [directory...]
use [-a|--append] directory [directory...]
Prepend directory to the MODULEPATH environment
variable. The --append flag will append the
directory to MODULEPATH.

However, what actually happens depends on the initial contents of
MODULEPATH. For example:

$ module use /tmp
$ module use /home
$ echo $MODULEPATH
/home:/tmp
$ module use /tmp
/home:/tmp

So it appears that the search order in the MODULEPATH will not change if a
specified directory is in the initial MODULEPATH. This applies to at least
the following versions of modules - 3.2.6 & 3.2.7 (C-version) and 1.146
(TCL-version).

The actual behaviour of the "module use" could be considered a bug,
because it does not conform with the manpage. This "bug" could be
addressed in a few ways, such as:

1. Change the manpage to describe the actual behaviour.
2. Change the actual behaviour to match the manpage.
3. Avoid "module use" commands and set MODULEPATH directly.

I would prefer option 2 over option 1, because the current behaviour can
cause confusing errors in scripts. For example, if a script inherits a
MODULEPATH from the environment, the MODULEPATH may not be set as expected
by an internal "module use" command. Option 3 avoids the problem, but it
may not be future-proof.

 ----------------------------------------------------------------------

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/modules/bugs/60/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/prefs/

--
mein@cs.umn.edu
http://www.cs.umn.edu/~mein

Original comment by: sirdude

[xdelaruelle]

Hi Kent,

Example: say I have this:
/soft/rko-modules:/home/mein/.modules
If I do a module use /home/mein/.modules
should it do this or this? (assuming #2 is picked)
/home/mein/.modules:/soft/rko-modules:/home/mein/.modules
/home/mein/.modules:/soft/rko-modules

As far as I can tell, either option would produce the same results when searching for modulefiles. But the second option (removing the duplicate path) would prevent the MODULEPATH from growing, so it is probably more efficient in the long run.

I also think that having the same dir used multiple times should just
warn you that you already have that dir in your path and not make any changes.

I think it would be more useful to give the user what they have requested. Otherwise they may resort to a workaround such as setting MODULEPATH directly, which defeats the purpose of the 'module use' command.

Regards,
Milton.

Original comment by: mw00ds

[xdelaruelle]

In reply to Milton Woods (mw00ds@users.sf.net):

I think it would be more useful to give the user what they have requested.
Otherwise they may resort to a workaround such as setting MODULEPATH
directly, which defeats the purpose of the 'module use' command.

Regards,
Milton.

Hi Milton,

I'm really not trying to argue with you, though it may sound like it. :)
I do see the merits of what your proposing and I do like your option
as an alternative.

Giving the user what they requested though is the tricky bit. After
reading the man page it was not clear at all what the behavior was to
me from reading it. A lot of bug reports/feature requests I've gotten
for modules where very subjective and people tend to suggest a fix that
fits their needs at the time while not looking at the bigger picture.
(I'm not saying thats what your doing in this case.)

I saw the ticket and wanted to share my option of things to give an
alternate opinion. I'm ok with any picked solution, however I think that
the documentation should be updated to make it clear how it actually
works.

Kent

Original comment by: sirdude

[xdelaruelle]

Hi Kent,

Thanks for taking an interest in the issue. I agree that there are several possible solutions, but I do have a strong preference for "fixing" the code instead of the manpage.

Giving the user what they requested though is the tricky bit. After
reading the man page it was not clear at all what the behavior was to
me from reading it.

The manpage seems fairly unambiguous to me:

use directory [directory...]
use [-a|--append] directory [directory...]
  Prepend directory to the  MODULEPATH  environment
  variable.   The  --append  flag  will  append the
  directory to MODULEPATH.

Directories are either prepended or appended to MODULEPATH. There is no mention of conditional behaviour if a directory is already in MODULEPATH.

Of course, there are some special cases that need to be handled but not necessarily explained in the manpage. For example, the handling of duplicate directories in MODULEPATH is undocumented, but whatever action is taken should not change the documented behaviour. Another undocumented feature is that 'module use' refuses to accept a directory that does not exist - but that behaviour seems reasonable and is quite predictable.

I agree with you that, no matter what solution is chosen, the documentation should describe how the software actually works. But in this case, I am quite satisfied with the documented behaviour and I would like the software to work "as advertised".

Regards,
Milton.

Original comment by: mw00ds

[xdelaruelle]

I will implement option 1 aka the manpage update.

Option 2 could be done later on if someone is still interested on this behavior change. It could be implemented as a configurable option, to let people decide the behavior they want and avoid breaking current behavior for people relying on it.

Such change should also impact the append-path and prepend-path modulefile commands as they currently behave like module use: path position is currently not changed if path is already defined in variable