Skip to content

fix modpath_extensions_for method: take into account modules in Lua syntax#1766

Merged
boegel merged 16 commits intoeasybuilders:developfrom
boegel:1473_modpath_extensions_for_lua
May 18, 2016
Merged

fix modpath_extensions_for method: take into account modules in Lua syntax#1766
boegel merged 16 commits intoeasybuilders:developfrom
boegel:1473_modpath_extensions_for_lua

Conversation

@boegel
Copy link
Copy Markdown
Member

@boegel boegel commented May 17, 2016

wrapper PR for #1474 by @t-brown

(replacement for #1763)

boegel added a commit to boegel/easybuild-framework that referenced this pull request May 17, 2016
r'^\s*prepend-path\s+MODULEPATH\s+"?([^"\s]+)"?', # prepend to $MODULEPATH in Tcl modules
r'^\s*prepend_path\(\"MODULEPATH\",\s*\"(\S+)\"', # prepend to $MODULEPATH in Lua modules
])
modpath_ext_regex = re.compile(modpath_ext_regex, re.M)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't it make sense to determine beforehand which kind of module are we reading, and apply the appropriate regex for each kind, instead of packing them all together?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe, but what extra would that give us?

If we detect a Tcl module (which is easy, via the required %#Module header), then we still need to try two regex's: module use and prepend-path MODULEPATH...

It's not like this is going to result in a noticeable speedup: module files are quite small, and regex search in Python is quite fast. It may even be faster to do what we do now than figure out first which type of module we're dealing with and then searching with a regex...

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It wasn't performance what bothered me, but keeping things clean and well structured. But admittedly this is splitting hairs in this particular case.

@boegel
Copy link
Copy Markdown
Member Author

boegel commented May 18, 2016

Thanks for the review @wpoely86 and @damianam!

I ran into another bug when testing this thoroughly with Python-2.7.11-intel-2016a.eb, using HierarchicalMNS, Lmod + modules in Lua syntax and with --recursive-module-unload enabled. The path_to_top_of_module_tree function was not taking into account the .lua extension.

This has been fixed in here too now, and a dedicated unit test has been added.

I've retested this with the setup mentioned above, works like a charm now:

$ find . -type f | xargs ls -1rt
./Core/M4/1.4.17.lua
./Core/Autoconf/2.69.lua
./Core/Automake/1.15.lua
./Core/libtool/2.4.6.lua
./Core/flex/2.5.39.lua
./Core/Autotools/20150215.lua
./Core/Bison/3.0.4.lua
./Core/zlib/1.2.8.lua
./Core/binutils/2.25.lua
./Core/GCCcore/4.9.3.lua
./Compiler/GCCcore/4.9.3/M4/1.4.17.lua
./Compiler/GCCcore/4.9.3/flex/2.5.39.lua
./Compiler/GCCcore/4.9.3/Bison/3.0.4.lua
./Compiler/GCCcore/4.9.3/zlib/1.2.8.lua
./Compiler/GCCcore/4.9.3/binutils/2.25.lua
./Core/icc/2016.1.150-GCC-4.9.3-2.25.lua
./Core/ifort/2016.1.150-GCC-4.9.3-2.25.lua
./Core/iccifort/2016.1.150-GCC-4.9.3-2.25.lua
./Compiler/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150.lua
./Core/iimpi/8.1.5-GCC-4.9.3-2.25.lua
./Core/intel/2016a.lua
./Core/iimpi/2016.01-GCC-4.9.3-2.25.lua
./MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/imkl/11.3.1.150.lua
./MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/bzip2/1.0.6.lua
./MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/zlib/1.2.8.lua
./MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/ncurses/6.0.lua
./MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/libreadline/6.3.lua
./MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/Tcl/8.6.4.lua
./MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/SQLite/3.9.2.lua
./MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/Tk/8.6.4-no-X11.lua
./MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/M4/1.4.17.lua
./MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/Autoconf/2.69.lua
./MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/Automake/1.15.lua
./MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/libtool/2.4.6.lua
./MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/Autotools/20150215.lua
./MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/GMP/6.1.0.lua
./MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/Python/2.7.11.lua
$ cat MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/Python/2.7.11.lua
help([[Python is a programming language that lets you work more quickly and integrate your systems
 more effectively. - Homepage: http://python.org/]])

whatis([[Description: Python is a programming language that lets you work more quickly and integrate your systems
 more effectively. - Homepage: http://python.org/]])

local root = "/tmp/software/MPI/intel/2016.1.150-GCC-4.9.3-2.25/impi/5.1.2.150/Python/2.7.11"

conflict("Python")

load("imkl/11.3.1.150")

load("bzip2/1.0.6")

load("zlib/1.2.8")

load("libreadline/6.3")

load("ncurses/6.0")

load("SQLite/3.9.2")

load("Tk/8.6.4-no-X11")

load("GMP/6.1.0")

prepend_path("CPATH", pathJoin(root, "include"))
prepend_path("LD_LIBRARY_PATH", pathJoin(root, "lib"))
prepend_path("LIBRARY_PATH", pathJoin(root, "lib"))
prepend_path("MANPATH", pathJoin(root, "share/man"))
prepend_path("PATH", pathJoin(root, "bin"))
prepend_path("PKG_CONFIG_PATH", pathJoin(root, "lib/pkgconfig"))
setenv("EBROOTPYTHON", root)
setenv("EBVERSIONPYTHON", "2.7.11")
setenv("EBDEVELPYTHON", pathJoin(root, "easybuild/MPI-intel-2016.1.150-GCC-4.9.3-2.25-impi-5.1.2.150-Python-2.7.11-easybuild-devel"))

-- Built with EasyBuild version 2.8.0.dev0
setenv("EBEXTSLISTPYTHON", "setuptools-18.7.1,pip-7.1.2,nose-1.3.7,numpy-1.10.1,scipy-0.16.1,blist-1.3.6,mpi4py-1.3.1,paycheck-1.0.2,argparse-1.4.0,pbr-1.8.1,lockfile-0.12.2,Cython-0.23.4,six-1.10.0,dateutil-2.4.2,deap-1.0.2,decorator-4.0.4,arff-2.1.0,pycrypto-2.6.1,ecdsa-0.13,paramiko-1.16.0,pyparsing-2.0.6,netifaces-0.10.4,netaddr-0.7.18,funcsigs-0.4,mock-1.3.0,pytz-2015.7,pandas-0.17.1,enum34-1.1.2,bitstring-3.1.3,virtualenv-14.0.5")

@boegel boegel merged commit ee9647f into easybuilders:develop May 18, 2016
@boegel boegel deleted the 1473_modpath_extensions_for_lua branch May 18, 2016 12:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants