Powershell: PSCore6 should have a way to use Windows PowerShell PSModulePath

[SteveL-MSFT]

With moving to .Net Std 2.0 and the PR to enable PSCore6 to load assemblies from the GAC, the missing piece to enable PSCore6 to replace the need for Windows PowerShell (majority of scenarios anyways) is to make it simpler for users to find and use in-box Windows modules. Currently, PSCore6 has no knowledge of the legacy Windows PowerShell PSModulePath. Since we know we don't have 100% compatibility with in-box modules (PSSnapIns, for example are not supported at all), it seems we should consider an opt-in approach. Alternatively, maybe we should have a Windows Compat module that has a whitelist of validated modules that work with PSCore6?

cc @joeyaiello @HemantMahawar

[joeyaiello]

In my mind, I've been thinking like:

• short-term is to finish startup config and put a value in there that concatenates Windows PS PSModulePath
• long-term is the compat module that helps with whitelists and warnings

We should do short-term, I think, before 6.0.

[SteveL-MSFT]

having a setting in StartupConfig is fine as a brute force way to get people to help us test compatibility, the compat module is something we can do separate from PSCore6 in the gallery perhaps and ideally driven by the community :)

[iSazonov]

We could add -LegacyModules switch to Import-Module cmdlet on Windows to enable search in legacy Windows PowerShell PSModulePath-s. Also it allow use $PSDefaultParameterValues.

[SteveL-MSFT]

@iSazonov it's not just Import-Module, but also Get-Module -ListAvailable. -ListLegacyModules might be ok as the long term we want everyone to have modules compatible with PSCore as well as available in the PSGallery.

[SteveL-MSFT]

Current thinking is to have this enabled by default (using a system default profile) in next beta release to make it easier to get user feedback. As we get closer to a release candidate, we'll make this opt-in.

[SteveL-MSFT]

For beta.4 we're adding a default profile to add Windows PowerShell path. Based on customer feedback, we'll decide in a later beta whether we should continue to do this and what the implementation should look like

[alexandair]

This change doesn't make sense on new Nano Server container.
This is what you see when you start microsoft/nanoserver-insider-powershell:

"WARNING: Appended Windows PowerShell PSModulePath"

PS C:\> $env:psmodulepath -split ';'
PowerShell\Modules
c:\program files\powershell\Modules
C:\Users\ContainerUser\Documents\WindowsPowerShell\Modules
C:\Program Files\WindowsPowerShell\Modules
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\

3 of those 5 paths are unnecessary on new Nano Server.

[SteveL-MSFT]

Based on the initial feedback, I think it makes sense to have the Windows PowerShell PSModulePath added by default as many modules just work (or seem so without exhaustive testing):

• [ ] Implement in the console host instead of userprofile
• [ ] Make configurable in startup json
• [ ] Blacklist or whitelist Windows PowerShell modules

This should also resolve https://github.com/PowerShell/PowerShell/issues/4339

[iSazonov]

What if no console?

[SteveL-MSFT]

In the no console (using PowerShell as library) case, the app is expected to manage the module paths.

[joeyaiello]

Questions we need to answer:

• default behavior in 6.0 (in the future, we probably can't remove the Windows PS because it's a breaking change)
• how do we expose changing it? (user profile, startup JSON, cmdlet, PS variable etc.)
  
  
  
  • specifically is something like Enable-WindowsPSModulePath sufficient for 6.0?
  
  
• is a whiltelist/blacklist desirable

[SteveL-MSFT]

After some discussion with my engineering team, I think the proposal for the 6.0.0 timeframe is to have a single cmdlet Enable-WindowsPSModulePath that users explicitly use to opt-in. All it does is the equivalent of what the interim solution does in the user profile. The primary reason to switch to opt-in is that we know many FullCLR modules don't work and we don't have time to work with partner teams to validate ones that partially work giving a false impression to the user if they show up by default with Get-Module -ListAvailable.

[joeyaiello]

@PowerShell/powershell-committee closed on shipping either an Enable-WindowsPSModulePath or Add-WindowsPSModulePath on the Gallery (and not the engine). Reasoning:

• we don't want to expose a bunch of modules that don't work yet
• in the future, we can expose modules that are known to work within PS 6.0/.NET Core 2.0
• this feels like a bit of a hack, and we don't want to be tied to keeping it forever
• there's still value in easily adding your Windows PSModulePath

[SteveL-MSFT]

https://www.powershellgallery.com/packages/WindowsPSModulePath/1.0.0

[iSazonov]

I suggest start with _white list_ of Windows PowerShell modules which we want to enable to load from Windows PowerShell module paths. The white list should contains only tested and approved modules.
Hence we dont need new cmdlets - we can implicitly use Windows PowerShell module paths (not in PSModulePath) and enhance Import-Module to check the white list _after_ module search in PSModulePath.

[SteveL-MSFT]

Long term, we may have a whitelist, but within the 6.0.0 timeframe, partner teams won't be able to validate compatibility with PSCore6 so the cmdlet is a stop gap solution.

[brwilkinson]

Can't you just stop modules from loading (in PSCore6) unless the correct information is published in the Module manifest ?

ClrVersion, DotNetFrameworkVersion, PowerShellHostVersion, PowerShellVersion

• Minimum version of the Windows PowerShell engine required by this module
  PowerShellVersion = ''

• Name of the Windows PowerShell host required by this module
  PowerShellHostName = ''

• Minimum version of the Windows PowerShell host required by this module
  PowerShellHostVersion = ''

• Minimum version of Microsoft .NET Framework required by this module. This prerequisite is valid for the PowerShell Desktop edition only.
  DotNetFrameworkVersion = ''

• Minimum version of the common language runtime (CLR) required by this module. This prerequisite is valid for the PowerShell Desktop edition only.
  CLRVersion = ''

Any modules with that info will not load down level so that should be safe?! e.g. PowerShellVersion ='6.0'

Perhaps rewrite the Get-Module -ListAvailable Cmdlet (in PSCore6) so it only shows up modules with the correct manifest info. Add a Force parameter for people to bypass the safe behavior and allow them to view all modules.

Do the same thing for Import-Module. Force will allow them to load any module.

I don't know enough about module autoloading to know what might be needed there, however I am sure it can also use the same information?

Perhaps this overhead would cause some performance issues ? However ideally people will remove any non PSCore6 modules from their machines over time. Obviously that is the goal anyway.

If this was the behavior then, you would publish PSModulePath by default in PSCore6.

[MaximoTrinidad]

Guys!

Long before the implementation of: Appended Windows PowerShell PSModulePath in PoweeShell Core, I mention its was a bad idea and knowing that Windows PowerShell fullCLR is not supported in PowerShell Core,

We should not include Windows PowerShell modules in PowerShell Core PSModulePath, In my own opinion we should keep it separate,

Or at least give an option to turned it off.

:)