[Project Proposal] Modules

[xdelaruelle]

1. Name of Project

Modules

2. Project Description

Modules, also called Environment Modules, is a tool that enables user to dynamically handle the environment of their shell session. By evaluating environment scripts called modulefiles, Modules through its module command is able to update the current shell and later undo these changes. Modules handles change of environment variable, alias, function, completion, etc. It supports most known shells (bash, ksh, zsh, sh, csh, tcsh, fish, cmd, pwsh) and programming language (perl, ruby, tcl, python, cmake and R).

Modules is used since decades in the HPC community to provide access on supercomputers to the software catalog of HPC sites.

3. Statement on Alignment with High Performance Software Foundation's Mission

The Modules project aligns with the HPSF's mission.

Modules is a well known tool in the HPC community, used from the scientist laptop to the high-end supercomputer. The Modules project aims at constantly improving the module tool to ease the user experience when it is about to manage shell environment and access software catalog. The Modules project is committed to support the HPC ecosystem to promote quality and openness.

4. Project Website (please provide a link)

• https://envmodules.github.io/modules/
• https://github.com/envmodules/modules

5. Open Source License (please provide a link)

SPDX Identifier: GPL-2.0-or-later
COPYING.GPLv2

6. Code of Conduct (please provide a link)

Code of Conduct

7. Governance Practices (please provide a link)

Modules Governance

8. Two Sponsors from the High Performance Software Foundation's Technical Advisory Committee

Todd Gamblin and Damien Lebrun-Grandie

9. What is the project's solution for source control?

GitHub

10. What is the project's solution for issue tracking?

GitHub Issues

11. Please list all external dependencies and their license

Required dependencies:

• Tcl (TCL)

Installation/build dependencies:

• bash (GPL-3.0-or-later)
• make (GPL-3.0-or-later)
• sed (GPL-3.0-or-later)
• runtest (GPL-3.0-or-later)
• grep (GPL-3.0-or-later)
• gcc (GPL-3.0-or-later)
• autoconf (GPL-2.0-or-later)
• automake (GPL-2.0-or-later)
• autopoint (GPL-3.0-or-later)
• m4 (GPL-3.0-or-later)
• python (Python-2.0.1)
• sphinx (BSD-2-Clause AND MIT)
• tar (GPL-3.0-or-later)
• gzip (GPL-3.0-or-later)
• uname (GPL-3.0-or-later)
• manpath (GPL-3.0-or-later)
• git (GPL-2.0-only)
• basename (GPL-3.0-or-later)

Some extra features of Modules relies on the following external software:

• less (GPL-3.0-only and BSD-2-Clause)
• logger (BSD-4-Clause-UC)
• nagelfar.tcl (GPL-2.0-or-later)

12. Please describe your release methodology and mechanics

Modules has 2 feature releases per year: one during the first half of the year, the second before the ACM/IEEE Supercomputing (SC) Conference. Bug fix releases are done on an ad-hoc basis according to the severity of bugs found on a supported feature release.

The technical process for drafting a Modules release is described in the Create new Modules release guide.

Only Modules lead developer has the permission to draft a Modules release.

13. Please describe Software Quality efforts (CI, security, auditing)

Modules project follows a Test-Driven Development approach. Thus a significant part of the development time on Modules is focused on testing. As a result, Modules now integrates 22k integration tests, 1k installation tests and code linting tests.

All these tests help to properly cover the numerous behavior of each feature. Code is currently covered by tests at 99.5%.

Test suites are relying on the DejaGnu framework. Tcl code linting is done with Nagelfar and shell code linting is done with ShellCheck.

Continuous Integration is extensively used to run the test suites against different installation configuration over a variety of OSes: FreeBSD, OSX, Windows and Linux (Ubuntu, EL, OpenSUSE).

For our CI needs, we are using GitHub Actions and Cirrus CI. Code coverage is measured with CodeCov.

Modules uses GitHub's private security reporting and we commit to provide fixes for a defined list of supported releases.

14. Please list the project's leadership team

• Xavier Delaruelle, lead developer and project maintainer

15. Please list the project members with access to commit to the mainline of the project

• Xavier Delaruelle

16. Please describe the project's decision-making process

We aim for consensus-driven decision making. New development are presented on project's mailing-list. Feedbacks from mailing-list's members are taken into account or debated to adjust the development made.

Reviews of pull requests must be approved and merged by project's leadership team.

17. What is the maturity level of your project?

The Modules project has a long history and is quite mature. However this maturity does not mean development is stalled. There are still numerous new ideas to incorporate ans new use cases to support. Thus 2 new feature releases are published every year with a specific aim at not breaking things. This point is guarantied by the applied test-driven development methodology and the resulting large test suites.

18. Please list the project's official communication channels

Official communication channels are:

• The modules-interest mailing-list (on SourceForge) where users ask questions, sysadmins/developers suggest features and where project's news are relayed
• GitHub issues and PRs
• Social media accounts (see below) that relay project's news

19. Please list the project's social media accounts

• X/Twitter: @EnvModules
• Mastodon: @[email protected]
• Bluesky: @EnvModules.bsky.social

20. Please describe any existing financial sponsorships

Contributors are primarily paid by their own institution to work on Modules, though many also use their free time to contribute to the project.

The work on the logo of the project was paid by CEA in 2020.

All technical resources used by the project are currently freely provided by:

• GitHub (source repository, CI, website, files)
• SourceForge (files, mailing-list, website)
• Cirrus CI (CI)
• CodeCov (code coverage)
• ReadTheDocs (doc website)

21. Please describe the project's infrastructure needs or requests

The Modules project would like to request:

• CI resources to run the extensive test suites of the project (free and diverse resources provided by GitHub Actions and Cirrus CI are currently sufficient, but in the event of a policy change of these providers compute resources would be needed)
• a dedicated domain name like envmodules.io

[ax3l]

Thank you for the great presentation today and discussion in the HPSF TAC meeting!

We were going a bit back and forth on the maturity level, between Sandbox and Established because of the following:
Since the project is currently single-maintainer but actively seeks to grow its steering committee, with a governance structure in place, it meets much of the requirements of the established stage.

With regard to the code-review criteria, this is currently only possible for external contributors and external PRs are being reviewed and merged. At the same time, there is impressive (near-perfect) code coverage in the project and clearly extremely wide usage, active development and history.

Something that was raised would make people on the TAC more at ease was if there would already be multiple members, but the lifecycle document under possible characteristics explicitly lists:

Projects that are looking to create a lifecycle plan (maintainership succession, contributor programs, version planning, etc.).

So we agreed that Established is sensible for the presented project and its major component in the HPC ecosystem. We will vote per usual in the coming week(s) on the criteria and @xdelaruelle is available for follow-up questions

[xdelaruelle]

modules_hpsf_tac-20250123.pdf

Many thanks TAC members for your warm welcome and attentiveness. Please find attached the slides presented today.

[xdelaruelle]

Small update: we are progressing well drafting the Technical Charter for the project with Linux Foundation. I have added the current draft version of this document in the code repository, and updated governance document accordingly:

• https://modules.readthedocs.io/en/latest/CHARTER.html
• https://modules.readthedocs.io/en/latest/GOVERNANCE.html

[jlapolla-cray]

I'm taking a look at Modules testing.
I found a Codecov Report in the following pull request, but the hyperlink to the full report is broken.
envmodules/modules#537

@xdelaruelle, can you post a link to an example of a recent test run?
The GitHub Actions workflow runs seem to be restricted to linting and installation testing.

[xdelaruelle]

You may find code coverage result from last commit on main here:
https://app.codecov.io/gh/envmodules/modules/commit/c4b0f96df92ba5957bf5498a1e493b51573eea77/tree

On the CI side, in addition to linting jobs (lint) and installation-specific jobs (native-cmd and native-pwsh) you will find non-regression tests + installation tests under the windows-tests and linux-tests jobs on GitHub Actions and with all Cirrus CI tests.

You may access the list of these jobs here:
https://github.com/envmodules/modules/pull/537/checks

Each of these test jobss runs the non-regression testsuite (+20k tests) and the installation testsuite (+1k tests). CI jobs cover the following environments: 2 Windows (Cygwin and MSYS), 12 Linux (9 Ubuntu, 2 EL, 1 OpenSuse), 1 FreeBSD, 1 OS X. The Linux tests cover different configuration sets and version of Tcl (8.5, 8.6, 8.7 and 9.0).

You may dive in the result of Cirrus CI jobs here for instance:
https://cirrus-ci.com/build/4841662695866368

[jlapolla-cray]

Thank you.
The runtest output is indeed in the GitHub Actions workflow run log, I just didn't see it before.
And I discovered that I can reach the test results by clicking on the badges on the repository's main page.
Seems obvious in retrospect, but I didn't think of it initially.

[jlapolla-cray]

@xdelaruelle, can you provide hyperlinks that provide evidence that Modules is being used successfully in production by at least three independent end users?
For example, see the hyperlinks that Charliecloud provided in the "17. What is the maturity level of your project?" section here: #28

[xdelaruelle]

Three different computing centers mention usage of Environment Modules in their documentation:

• CEA: https://hpc.cea.fr/tgcc-public/en/html/toc/fulldoc/Environment_management.html
• IDRIS: http://www.idris.fr/eng/jean-zay/cpu/jean-zay-cpu-doc_module-eng.html
• LRZ: https://doku.lrz.de/environment-modules-10745963.html

You can also see that Modules is widely distributed on a variety of OSes: https://repology.org/project/environment-modules/versions

Looking at the public archives of the mailing-list, you can find various people reporting their usage: https://sourceforge.net/p/modules/mailman/modules-interest/

[slandath]

Poll Results

Resolution	Approve	Against	Abstain	Result
That Modules meets all requirements to be a Linux Foundation project.	9	2	1	Approve
That Modules has 2 TAC sponsors to champion the project and provide mentorship as needed.	10	0	2	Approve
That Modules has a charter document with an intellectual property policy that leverages open licenses, including, in the case of contributions of code, the use of one or more licenses approved as “open” by the Open Source Initiative.	12	0	0	Approve
That Modules has a code of conduct.	11	0	1	Approve
The Modules has a publicly available governance document.	10	2	0	Approve
That Modules has documented that the project is being used successfully in production by at least three independent end users which, in the TAC’s judgment, are of adequate quality and scope.	12	0	0	Approve
That Modules has demonstrated development processes (e.g., use of pull requests, code review, testing, CI) that lower barriers to contribution and ensure software quality necessary for increased adoption.	8	0	4	Approve
That Modules has demonstrated a substantial ongoing flow of commits and merged contributions.	9	2	1	Approve