[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