You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature Request: Prevent installations of incompatible PSEditions #71
By default, modules that are marked as incompatible with the PSEdition in use should not be installed. The current behavior results unnecessarily in incompatible modules being installed and causing issues later.
Below, Posh-Git is given as an example, since it is tagged with PSEdition_Core, but can be installed, without any warning on WIndows PowerShell.
Ideally, both modules tagged with PSEdition_Core and not tagged with PSEdition_Desktop should result in an error (or at least a ShouldContinue prompt) when installed on Windows PowerSHell, and modules with PSEdition_Desktop but not PSEdition_Core should be similarly guarded from installation on PowerShell Core.
Steps to reproduce
In WIndows PowerShell:
Install-Module posh-git -AllowPrerelease
Expected behavior
Error saying that this module is incompatible with the current PowerShell Version
The module manifest can explicitly include PSCompatibleEditions https://docs.microsoft.com/en-us/powershell/gallery/concepts/module-psedition-support). PowerShellGet will provide the behavior you want in this case (unless there's a bug I'm unaware of). However the downside is that PowerShell 4 and below will refuse to load the module at all with this value in the manifest. This is one reason why some modules don't include this.
The module can include PSEdition_Desktop and PSEdition_Core tags. These are advisory only - PowerShell and PowerShellGet code doesn't pay any attention to them.
So, module authors have the option to get the behavior you want. It's obviously possible to apply semantics to the tags as well but I'm a bit concerned that'd be a breaking change.
Also possible: milder things like warn authors if they tag but don't set the edition in the manifest.
This should be an opt-in check like -AuthenticodeCheck. When -PSEditionCheck is passed then if CompatiblePSEditions is defined in the module manifest it uses that to validate editions. There could be some consideration if tags should be used if CompatiblePSEditions is not defined.
Activity
edyoung commentedon Apr 7, 2019
There are 2 mechanisms to specific PSEdition:
The module manifest can explicitly include PSCompatibleEditions https://docs.microsoft.com/en-us/powershell/gallery/concepts/module-psedition-support). PowerShellGet will provide the behavior you want in this case (unless there's a bug I'm unaware of). However the downside is that PowerShell 4 and below will refuse to load the module at all with this value in the manifest. This is one reason why some modules don't include this.
The module can include PSEdition_Desktop and PSEdition_Core tags. These are advisory only - PowerShell and PowerShellGet code doesn't pay any attention to them.
So, module authors have the option to get the behavior you want. It's obviously possible to apply semantics to the tags as well but I'm a bit concerned that'd be a breaking change.
Also possible: milder things like warn authors if they tag but don't set the edition in the manifest.
ThomasNieto commentedon Jul 11, 2023
This should be an opt-in check like
-AuthenticodeCheck. When-PSEditionCheckis passed then ifCompatiblePSEditionsis defined in the module manifest it uses that to validate editions. There could be some consideration if tags should be used ifCompatiblePSEditionsis not defined.