Let users and sites define their own sub-command aliases #712

The set of module sub-command names and their aliases is fixed in the code (add for load, rm for unload, show for display, ...). There is no way for a user or a site to declare additional aliases to map a sub-command onto a name they are more used to.

Feedback gathered at the HPSF Conference 2026 showed that users juggling several tools find it confusing that the same kind of action goes by a different name in each of them. Spack was the recurring example: it uses spack find to list installed packages and spack list to list available ones, where Modules uses module list for loaded modules and module avail for available ones. A user switching between the two tools regularly types the Spack name on the module side and gets an error instead of the expected result. Other tools (package managers, container runtimes, environment managers) have their own vocabulary and raise the same friction with other sub-command names.

The need is for a way to declare sub-command aliases, so that for instance module find resolves to module avail or module ls resolves to module list. Such definitions should be possible at two levels:

• site-wide, so that an administrator can harmonize the module vocabulary with the other tools deployed on the system,
• per-user, so that an individual can map the names they are used to without affecting others.

An alias should behave exactly like the sub-command it maps to: same arguments, same options, same output and same shell completion. Aliases should be visible to users (for instance in the sub-command listing of module help) so the mapping is discoverable and not a hidden surprise. It should not be possible for an alias to shadow a built-in sub-command name, to keep documented behaviors stable.

This would make module friendlier to users coming from other ecosystems and would let sites present a consistent command vocabulary across their toolchain.