Support for PowerShell/pwsh

[kheaactua]

Is your feature request related to a problem? Please describe.

Being able to use PowerShell/pwsh with Environment Modules would be really helpful

Describe the solution you'd like

The ability for Environment Modules to interact with the $env object.

Additional context

I was able to install Environment Modules using the WSL to build it (15158c3323edb) and then running INSTALL.bat, and then even set up a PS function to use module, i.e.

$env:MODULESHOME = "$env:HOMEPATH\workspace\modules\install"
if (Test-Path $env:MODULESHOME)
{
    $env:MODULES_CMD="$env:MODULESHOME\libexec\modulecmd.tcl"
    function module {
        &"$env:MODULESHOME\bin\module.cmd" $args
    }

    $my_modules = "$env:HOMEPATH\dotfiles\modulefiles";
    if (Test-Path $my_modules)
    {
        write-host " Adding $my_modules" -ForegroundColor Yellow
        $env:MODULEPATH="$my_modules" # module use doesn't seem to work
    }
}

But at the end of the day I don't think Environment Modules is able to interact with the environment properly. Even even I got module load sort of working (using a full path because it can't seem to read MODULESHOME, it can't write to my environment.

It seems like it's so close to working. It works in CMD, I just never use CMD..

[xdelaruelle]

As you say currently only the CMD shell is supported for the Windows platform.

A pull request adding PowerShell support to Modules will be welcomed.

[xdelaruelle]

A few hints for anyone willing to address this feature request.

modulecmd.tcl.in has to be updated to produce pwsh shell output. A pwsh case should be added to the switch structure in:

• renderFalse procedure to output a false shell statement
• renderTrue procedure to output a true shell statement
• renderText procedure to echo text
• renderSettings procedure to:
  • define environment variable
  • unset environment variable
  • define shell alias (if this concept applies to PowerShell)
  • unset shell alias
  • define shell function (if this concept applies to PowerShell)
  • unset shell function
  • execute xrdb command to define XResources
  • execute xrdb command to unset XResources
  • execute PowerShell change directory command
• renderAutoinit to output pwsh code to define the module function for the shell

pwsh should also be added to the list of supported shells.

It may also be useful to have a dedicated init scripts for pwsh like init/bash.in, that mainly calls modulecmd.tcl pwsh autoinit to get PowerShell module function defined. But this part could be addressed in a second phase.

I will handle the testsuite part.

[gsal]

It does not look that difficult and I would like to take a shot at it.

[gsal]

It looks like the word module is already taken in PowerShell. What to use, instead? modules? envmodule? ... ? Oh, just noticed that some of the files in the repo actually have the name envmodules...another candidate.

[xdelaruelle]

envmodule seems appropriate

[wenzler]

Nah, make it powermodule ;)

[gsal]

So, how to proceed?

I have never contributed to an open source project and, certainly, I don't quite understand a lot of the repo structure and those *.in files. For sure, the repo seems to have waaay too much content compared to what I got when downloading modules-4.6.0-win.zip

Having said that, I have made some progress and have what seems to be a working version; at least, regarding the limited way in which I use modules.

As per your hints in previous post, I have included into modulecmd.tcl most of the items listed above; except those for renderSettings:XRDB and renderAutoinit.

As agreed, I renamed the command from module to envmodule (even the one for cmd, for consistency).

Then, for every *.bat and *.cmd files, I created a corresponding *.ps1; except for envml.cmd. This last file looks a bit confusing and I don't know much batch scripting...heck, I did not know any PowerShell scripting, either, until about 3 days ago, but at least PowerShell scripting may be worth learning.

Anyway, I figured a single installation may support both cmd and pwsh; so, this is what the deployment looks like:

├── INSTALL.ps1
├── TESTINSTALL.ps1
├── UNINSTALL.ps1
├── bin
│   ├── envml.cmd
│   ├── envml.ps1
│   ├── envmodule.cmd
│   ├── envmodule.ps1
│   ├── ml.cmd
│   └── ml.ps1
├── doc
│   ├── CONTRIBUTING.txt
│   ├── COPYING.GPLv2
│   ├── ChangeLog
│   ├── INSTALL-win.txt
│   ├── MIGRATING.txt
│   ├── NEWS.txt
│   ├── README
│   ├── module.txt
│   └── modulefile.txt
├── init
│   ├── cmd.cmd
│   └── pwsh.ps1
├── libexec
│   └── modulecmd.tcl
└── modulefiles
    ├── module-git
    ├── module-info
    └── null

Even without envml.ps1 (the figure above shows one, but it is currently empty), the above deployment works for me in pwsh and the tests all pass:

❯ C:\Programs\envmodules\4.6.0\win10\TESTINSTALL.ps1
'envmodule' command found.
'ml' command found.
'envml' command found.
'envmodule -V' worked.
'envmodule list' worked.
'ml' test passed.
'envmodule load null' worked.
'envmodule list -t' test passed.
'ml -t' test passed.
'ml -null' worked.
No Modulefiles Currently Loaded.
'envmodule list' test passed.
No Modulefiles Currently Loaded.
'ml' test passed.

Anyway, please advise.

[gsal]

Ok, done with envml.ps1, too. Decided to ignore most of the contents of envml.cmd and simply pay attention to "usage" as my program specification and implemented an envml.ps1, from there...hope I got it right.

[xdelaruelle]

@gsal Some guidelines to contribute:

• take into account what is written in the contributing guide
• fork this github repository
• create a branch to work on, on your git fork
• commit your development. I would expect several commits for this development (one for changes made to modulecmd.tcl, one for the initialization script, one for documentation, non-regression test addition, ...)
• propose these commits via a github pull request
• from there we will be able to exchange via this pull request

One important thing: the addition of a new feature should not break existing stuff. So there should be no change to the .cmd files, especially when using cmd shell you should still find a module command, it should not be renamed for this shell.

If PowerShell supports shell function, the module command should be defined this way, through an initialization script. The .cmd files are there because the cmd shell cannot define module via a shell function.

[Desjajja]

Any update on this issue?