Bug 1139165 - modulecmd is unusable ; 'MODULEPATH' not set
Summary: modulecmd is unusable ; 'MODULEPATH' not set
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: environment-modules
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Orion Poplawski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1443124 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-08 09:22 UTC by Clément DAVID
Modified: 2018-02-24 08:28 UTC (History)
5 users (show)

Fixed In Version: environment-modules-4.1.1-1.fc28
Clone Of:
Environment:
Last Closed: 2018-02-20 08:31:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
/usr/share/Modules/etc/rc (522 bytes, text/plain)
2018-02-24 08:28 UTC, Xavier Delaruelle
no flags Details

Description Clément DAVID 2014-09-08 09:22:37 UTC
Description of problem:

After installing openmpi I just want to load the associated module. The load failed with a 'MODULEPATH' no set.


Version-Release number of selected component (if applicable):
environment-modules-3.2.10-6.fc20.x86_64

How reproducible:
Always

Steps to Reproduce:
1. modulecmd sh load mpi/openmpi-x86_64

Actual results:

$ modulecmd bash load mpi/openmpi-x86_64
locate_module.c(245):ERROR:107: 'MODULEPATH' not set
ModuleCmd_Load.c(208):ERROR:105: Unable to locate a modulefile for 'mpi/openmpi-x86_64'

$ file /etc/modulefiles/mpi/openmpi-x86_64
/etc/modulefiles/mpi/openmpi-x86_64: ASCII text


Expected results:

The PATH env variable should be updated.

Additional info:

Comment 1 Orion Poplawski 2014-09-08 13:41:17 UTC
Did you get a new shell after installing?

Comment 2 Clément DAVID 2014-09-09 06:25:15 UTC
No, I just installed it then try to use it.

Comment 3 Orion Poplawski 2014-12-05 23:55:34 UTC
Yeah, that doesn't work.

Comment 4 Pavel Raiskup 2017-11-10 17:56:57 UTC
*** Bug 1443124 has been marked as a duplicate of this bug. ***

Comment 5 Pavel Raiskup 2017-11-10 17:59:54 UTC
(In reply to Orion Poplawski from comment #3)
> Yeah, that doesn't work.

Then it is a bug, at least IMO.  There should be some default module path,
so we don't have to strictly depend on shell profiles being loaded in.

In bug 1443124 I mentioned:
$ sudo bash -c '/usr/bin/modulecmd bash load existing-scl'
locate_module.c(245):ERROR:107: 'MODULEPATH' not set

It is really brittle to depend on env var;  could we rather have some default
path for modules hardwired directly into modulecmd?  This is blocker for SCLs.

Comment 6 Xavier Delaruelle 2017-11-11 16:51:42 UTC
(In reply to Pavel Raiskup from comment #5)
> It is really brittle to depend on env var;  could we rather have some default
> path for modules hardwired directly into modulecmd?  This is blocker for
> SCLs.

Some hints to help you on this issue:

* Starting version 4.0, module sources a Tcl rc file each time it is called. This rc file may contain the "hardwired" code you describe.

* However this sourced-rc mechanism requires either the MODULERCFILE or MODULESHOME environment variables to be set, to locate the rc-file to source. So there are still dependencies to the environment context. I will ajust code for next feature release (4.1) to overcome that and use rc file location path configured at build time.

* A workaround on the current module version you use may be to specify the modulefile to load as a full pathname.

Comment 7 Xavier Delaruelle 2018-02-15 19:29:19 UTC
With what is described on the above comment and the release of version 4.1.0 configuration could be done to handle this use case. This ticket can be closed.

Comment 8 Pavel Raiskup 2018-02-20 09:12:37 UTC
(In reply to Xavier Delaruelle from comment #6)
> * However this sourced-rc mechanism requires either the MODULERCFILE or
> MODULESHOME environment variables to be set, to locate the rc-file to
> source. So there are still dependencies to the environment context. I will
> ajust code for next feature release (4.1) to overcome that and use rc file
> location path configured at build time.

Xavier, can you please send a link to patch implementing this?

Comment 9 Xavier Delaruelle 2018-02-24 08:28:32 UTC
Created attachment 1400145 [details]
/usr/share/Modules/etc/rc

I attach you an example "/usr/share/Modules/etc/rc" global RC file which will define MODULEPATH environment variable, based on /usr/share/Modules/init/.modulespath content, if this variable is found undefined or empty.

With this global RC file, default MODULEPATH value is setup in case modulecmd is run through sudo:

$ sudo modulecmd bash use
MODULEPATH_modshare=/usr/share/modulefiles:1:/etc/modulefiles:1:/usr/share/Modules/modulefiles:1; export MODULEPATH_modshare;
MODULEPATH=/usr/share/Modules/modulefiles:/etc/modulefiles:/usr/share/modulefiles; export MODULEPATH;
test 0;
Search path for module files (in search order):
  /usr/share/Modules/modulefiles
  /etc/modulefiles
  /usr/share/modulefiles


Note You need to log in before you can comment on or make changes to this bug.