Module extension and actual module sharing same name but correspond to different software

[xdelaruelle]

Several module extensions use a name also used by actual modulefiles but are related to a different software than these modulefiles.

For example, R-tesseract-5.2.1-foss-2023a.eb generates a R-tesseract/5.2.1 modulefile that provides module extension tesseract/5.2.1 and loads module tesseract/5.3.4, generated by tesseract-5.3.4-GCCcore-12.3.0.eb. Here the actual tesseract/5.3.4 modulefile refers to Tesseract, an optical character recognition engine, whereas the tesseract/5.2.1 extension refers to the R extension for using tesseract.

Such name clash brings confusion at the module level as users see the teserract name used for a module and an extension, but not referring to the same thing.

For this example with R-tesseract-5.2.1-foss-2023a.eb, the module extension may be omitted as what is provided is already conveyed by the R-tesseract module name.

I would suggest to review all extensions whose names also correspond to module names. In case extension and module do not refer to the same software:

• avoid defining the extension in the modulefile if it corresponds to name of this modulefile
• in other case, rename the extension (for instance by prefixing it by the language name: python-, R-)

As it seems that module extensions only have an informational purpose, extension name change should not break a thing at the module level.

[xdelaruelle]

I have made some analysis using the current develop branch:

• easyconfigs: 582fc695
• easyblocks: 6a532731
• framework: 28cb2d2

I have tried to build all EB files for the following toolchains:

• foss: 2025a, 2024a, 2023b, 2023a, 2022b, 2022a
• intel: 2025a, 2024a, 2023b, 2023a, 2022b, 2022a
• GCCcore: 10.3.0, 11.1.0, 11.2.0, 11.3.0, 11.4.0, 12.1.0, 12.2.0, 12.3.0, 13.1.0, 13.2.0, 13.3.0, 14.1.0, 14.2.0, 14.3.0, 15.1.0

The list of EB files to build was obtained the following way:

ls easybuild-easyconfigs/easybuild/easyconfigs/*/*/*-foss-202{2,3,4,5}?.eb \
   easybuild-easyconfigs/easybuild/easyconfigs/*/*/*GCCcore-1*.eb \
   easybuild-easyconfigs/easybuild/easyconfigs/*/*/*-intel-202{2,3,4,5}?.eb \
| while read eb_file; do basename $eb_file; done >full_list

EB files were built the following way:

rm -rf ~/.local/easybuild
while read eb_file; do
  eb --module-naming-scheme=HierarchicalMNS --skip-sanity-check --skip-test-cases \
    --skip-test-step --robot --module-only $eb_file;
done <full_list

I obtained 3215 modulefiles. 6314 module extensions are provided. All names are available in the attached archive.

By comparing the names, I found 211 extension names that also are actual module names:

$ comm -1 -2 built_extension_name_list built_module_name_list | wc -l
211

eb_framework_4983.tar.gz

[boegel]

We can work on a sweep to fix these naming issues, but how would we prevent that going forward (by introducing an extra check in easyconfigs test suite)...

[xdelaruelle]

We can work on a sweep to fix these naming issues, but how would we prevent that going forward (by introducing an extra check in easyconfigs test suite)...

Yes, a new test that reads all EB files to fetch the name of all modules that may exist. Then compare with the extension names in modified EB file.

An attribute may be added in ext_list to state when an extension actually refer to a software also provided by a standalone EB file.

[lexming]

This is partially related to issue easybuilders/easybuild-easyconfigs#15004, which focuses on the shadowing of extensions with other versions.

The current situation is that EB does not check for name/version collision between extensions of different easyconfigs in the same toolchain. This can indeed lead to a broken environment. For instance, there is no guarantee that loading a module with an extension already provided by another loaded module will not break the underlying modules depending on that extension. Either because it is a different incompatible version or because it is a different software.

However, we need the option to shadow extensions in EB. Otherwise it might become practically impossible to ship certain software packages in a toolchain, as that would require developing a full new toolchain to avoid collisions.

So, my two cents is that on EB side we should definitely be more careful to minimize shadowing of extensions (in CI). But environment modules should also allow to load modules that shadow extension (through a config option), because in some cases it will be necessary.

[xdelaruelle]

@lexming Many thanks for your feedback. I am in line with you. The issue here is about using the same name for different things. Shadowing extension is an interesting use case and I have created envmodules/modules#584 to support that.