I want the ZIP install of PowerShell Core to use the current working directory as the installation directory for modules

Summary of the new feature / enhancement

As an user in a very restricted environment I cannot use PowerShell Core V7 on Windows 10 because of the following reasons acting simultaneously:

• I do not have Local Admin rights to the desktop as per corporate policy
• PowerShell Core will install all modules (Install-Module -Scope CurrentUser -Name SomeModule ) to the C:\Users\johndoe\Documents\PowerShell\Modules regardless of the $env:PSModulePath
• The Documents folder hierarchy has a corporate Anti-Virus policy and does not allow any DLL/EXE/.BAT/PS1/.VBS file to be executed. Therefore, install-module appears to work, but PWSH is unable to load any module.

All the above make it impossible to use any module thereby rendering PowerShell Core almost useless in my current work environment.

What workarounds did I try?

1. I installed the ZIP download of PowerShell Core in a local folder C:\Users\johndoe\mywork001, outside of Documents hierarchy to bypass Anti-Virus.
2. I tried tinkering with $env:PSModulePath in the vain hope that PWSH would start using the aforementioned folder for installing modules.
3. I tried altering the powershell.config.json as per this link , but this too did not work

Possible solution - inspired by NPM

Taking inspiration from Node Package Manager works (NPM) , PowerShell Core should not rely on a hard wired set of folder(s) for installing modules. Instead, it should be allowed to use the current working directory. Think of a package.json in the case of NPM and the JavaScript modules get installed in the node_modules sub-folder of the current working directory

Possible solution - inspired by powershell.config.json

I should be able to create a powershell.config.json in any folder c:\users\johndoe\mywork001\ and able to run pwsh.exe located in another folder by specifying the absolute path to the powershel.config.json as a command line argument. The PWSH.exe instance should follow the directions of the configuration file and install modules accordingly

Overarching idea

Make PWSH free from the shackles of CurrentUser and AllUsers scope. The CurrentUser/AllUser could still be retained as good to have options. I should be able to run side by side copies of PWSH using different versions of Modules , just like XCOPY of .NET or NODE.JS.

Proposed technical implementation details (optional)

Installing a module locally could look something like the following:

install-module -Name SqlServer -Scope Local

If this were NPM, then you would do the following:

npm install sqlserver

You will see the entry of SqlServer getting added to package.json and the Jascript code downloaded to node_modules folder.

The benefit of package.json is the ability to have SCM on your environment. You can reproduce your working folder by simply doing a npm install and all the packages listed in package.json will get downloaded with the right versions.

No response

[sdg002]

Thank you @alerickson and @daxian-dbw for taking time to look into this.

Yes - I managed to find a work around using a combination of Find-Module , Save-Module and alterations to $env:PSModulePath .
I will document the steps here , if in case somebody faces the same predicament as I did.

Background

• A team of quantitative energy analysts/data scientists in a trading company with strict corporate workstation policies
• They have free reign to use Python, Node and other development tool as long it does not require local admin rights.
• Trying to use PowerShell Core for some simple Azure automation (Infrastructure as a code) . e.g. Create a storage account and upload trading data to a storage account, etc.
• Windows 10 operating system (login via Citrix into a VDI)

What was the root cause?

• No local admin rights to the workstation as per Corporate policies

• The MyDocuments special folder C:\Users\johndoe\Documents has a strict Anti-Virus policy which disallows the Operating System from running any executable file, .VBS script, .PS script or load any .DLL from the MyDocuments folder

• To make matters more interesting the MyDocuments special folder C:\Users\johndoe\Documents is actually mapped to a Distributed File System. (to allow hot desking and working via VDI)

• The Install-Module cmdlet fails when I used -Scope AllUsers because of lack of admin rights

• The Install-Module cmdlet appears to succeed partially when I used -Scope CurrentUser. The assemblies get installed to C:\Users\johndoe\Documents\PowerShell\Modules folder as far as it can. When there is a chaim of dependent modules to be installed, then there is an abrupt failure down stream.

• Due to the strict AV policy on the MyDocuments folder, PowerShell is unable to load any cmdlet. E.g. Even if the DLLs of Az-Accounts were available in MyDocuments, then I would not be able to find or use the cmdlet Get-AzContext . Even Find-InstalledModule would not list Az.Accounts (the owner module of Get-AzContext)

• The error message is very fuzzy when I try to invoke a cmdlet. With the -verbose flag, it simply says could not load the module .... . A sensible error message would have saved me lots of hours and chasing around.

• Use has no rights to edit environment variables using the Control Panel --> System user interface. This makes editing any user specific environment variables onerous. Has to be scripted via PowerShell or Python.

What was the workaround?

Follow these steps when specifically installing any PWSH modules

• Create a folder C:\Users\johndoe\MyPowerShellModules
• Launch PWSH . Navigate to the above folder.
• Edit the environment variable $env:PSModulePath such that the path C:\Users\johndoe\Documents is removed from it. And, ensure that the path C:\Users\johndoe\MyPowerShellModules is appended to $env:PSModulePath
• Using a combination of Find-Module and Save-Module install your modules to this folder. You should see DLLs getting downloaded in the directory MyPowerShellModules ,

Follow this step for using PWSH for any other scenario

• Launch PWSH
• Once again, edit the environment variable $env:PSModulePath such that the path C:\Users\johndoe\Documents is removed from it. And, ensure that the path C:\Users\johndoe\MyPowerShellModules is appended to $env:PSModulePath
• You are now ready to use any cmdlet.
• Navigate away to your actual work folder and
• I would avoid installing any module in this session!

Suggestion

Improve the error message when -verbose flag is used

PowerShell should clearly state attempting to load DLL xyz.dll from path c:\blah1\blah2 and failed ... . The mentioning of the absolute path makes it very explicit for me.

Python and NodeJS have no problem in this scenario- why should PowerShell core suffer?

• Python has the venv or virtual environment system which allows PIP install to any folder of choice
• Node Package Manager can use npm install to a local folder and do what it needs to do.

This is my motivation for the suggestion that PWSH should be

• free from the concept of AllUsers and CurrentUser scope.
• PWSH should be free to use any local folder without going through the onerous manipulations of environment variables.
• PWSH should be free to install any version of cmdlet to the local folder (and take inspiration from packages.json of NPM and requirements.txt of python virtual environment and thus provide true side-by-side co-existence of modules with different versions)

Conclusion

• Yes. I was able to find a way out. But, it was a solution that was not trivial for other analysts to follow and implement. I have had to help out other analysts in setting it up.
• Debugging via Visual Studio Code has not been a smooth experience. It is not able to load cmdlets that I want (due to $env:PSModulePath)
• I tried tinkering with $Profile, but to no avail. This is also pointing to MyDocuments and AV prevent this script from getting loaded

PWSH is such a great scripting tool. This is one of the best things to come out of Micrsoft. I propose we make it even better. With the backing of .NET, sky is the limit for PWSH.

Thanks

[alerickson]

It’ll look at whatever paths are in $env:PSModulePath and find the next available path that ends in \Modules. If it doesn’t find any appropriate paths there, it’ll install to C:\Users\johndoe\Documents\PowerShell\Modules