Description
In an extmodules workflow, IPF can determine package name and version via three different methods:
lmod_cache
filename/directory name
key/value pairs in the module file itself
Currently, IPF assumes that any key/value pairs in the module file exist because the intent is for them to override any other values.
However, we've found at least one case (two versions) at TAMU where this is problematic:
These two entries are the two versions of the nvidia-container-cli package installed on Faster. The reason that they are getting ” ” for AppName and AppVersion is that in their module files (lua files), they list, for example:
local pkgName = "nvidia-container-cli"
local version = "1.13.2-1-hprc"
local base = pathJoin("/sw/hprc/sw/nvidia-container-cli/sw", version)
whatis("Name: " .. pkgName)
whatis("Version: " .. version)
IPF is doing a regex to look for a value after ’Name:’, it is not evaluating the lua file, so it thinks that the name (and version) is ” “.
Notably, IPF’s current behavior is to accept all metadata definitions that are explicitly specified in the module files themselves; metadata can be gathered from filenames/pathnames/lmod_cache, but values that are explicit in the module file will override the others.
We should note that information from the lmod_cache is, by definition, exactly the information that would be received by a "module spider" command, and thus canonical. Perhaps we need a flag for when the lmod_cache was used, and never override the name when it comes from an lmod_cache.
Even if lmod_cache is not being used, this problem could arise, so we should come up with a heuristic for which value for Name/Version to use.