At least to me it's unclear what you're proposing with respect to what could be done on the PowerShell side.

Note that, despite what https://github.com/cea-hpc/modules/blob/main/INSTALL-win.rst states, module is not a keyword in PowerShell, and I don't think there's a good reason not to put a module executable in $env:PATH, for the following reason:

• That submitting module works relies on PowerShell's rarely-used default-verb feature.
• That is, in the absence of any other form of a module command, it prepends Get- to the command and invokes the latter; that is module is then short for Get-Module

Not only is this inefficient, but it implies that anyone relying on this feature must be prepared to have it situationally preempted, namely if a command with this exact name is present, including an external executable.

In fact, a warning to this effect and a recommendation not to use the feature can be found in the about_Parsing help topic.

GitHub

modules/INSTALL-win.rst at main · cea-hpc/modules

Environment Modules: provides dynamic modification of a user's environment - cea-hpc/modules

If you want PowerShell integration then it sounds like you want to be able to change the environment variables while in PowerShell, this can only be done with a PowerShell script, cmdlet or dotnet assembly.

PowerShell is neither a POSIX shell, or an extension of CMD.EXE, so scripts and batch/command files have no effect on the PowerShell environment.

As noted, the word module already has an existing meaning in the PowerShell world, as the noun for all the cmdlets and functions that manage PowerShell modules. See

Get-Command -Noun Module

I suggest that what you need is a PowerShell module for your "Environment Modules" that exposes cmdlets for managing the environment according to your module definitions. For example, you may have one called Switch-Environment that changes the current $ENV set based on the modules.

For integration with PowerShell I recommend respecting the existing naming and conventions within PowerShell and also consulting the Approved Verbs for PowerShell.

While I don't know the specifics of how module works, its commands do run in-process in PowerShell, via PowerShell functions defined in https://github.com/cea-hpc/modules/blob/main/init/pwsh.ps1.in

That is, it is designed to support a number of shells, including PowerShell (albeit seemingly a WIP), by running shell-specific code in-process, which is the fundamental prerequisite for modifying a shell session's environment variables, with a unified set of command names across all supported shells.

No noun has special status in PowerShell; you can pass any string to Get-Command -Noun; e.g. function Test-Nothing {}; Get-Command -Noun Nothing

While there are conventions for what to call things, the nouns used by PowerShell itself are so generic that (Item, Date, ...) it would be impossible to advise against using those terms in other projects.

@TaiXeflar, apart from the $env:PATH issue (which, as discussed, shouldn't be one), please clarify what you think currently gets in the way of using this toolset in PowerShell and how the situation could be improved.

GitHub

modules/init/pwsh.ps1.in at main · cea-hpc/modules

Environment Modules: provides dynamic modification of a user's environment - cea-hpc/modules

Converting to a discussion since there doesn't seem to be a suggested action item.