Powershell: [7.0.0-rc.3] Some modules installed with PowerShell 7 are still marked "Desktop" only

[alexandair]

Some modules in PowerShell 7 installation folder are still marked as "Desktop" only (see attached image). Shouldn't they all be "Core" or "Desk, Core"?

Environment data

❯ $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.0.0-rc.3
PSEdition                      Core
GitCommitId                    7.0.0-rc.3
OS                             Microsoft Windows 10.0.18363
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[iSazonov]

/cc @SteveL-MSFT @daxian-dbw @PaulHigin @anmenaga

[alexandair]

Situation is not better in Azure Cloud Shell. Some of these modules are created by the PowerShell team.

[carlowahlstedt]

What command are you running to get that output?

[vexx32]

Some variant of Get-Module and/or Get-Module -ListAvailable I think? 🙂

[carlowahlstedt]

It was the second. Just FYI what macOS shows where one is something I installed specifically:

[anmenaga]

This is a duplicate of #7856
In that original issue powershell-committee decided that in cases above for modules that currently show 'Desk' (i.e. they haveCompatiblePSEditions manifest field missing) this field should be empty.
Feedback is welcome.

[alexandair]

@anmenaga All those modules are part of PowerShell 7. Why can't they be fixed and have a proper manifest? What to emit when the CompatilePSEditions field is missing is another issue and should be fixed too. "Desktop" is not the good solution.

[SteveL-MSFT]

The @PowerShell/powershell-committee design at the time is that if CompatiblePSEditions is not there, we can only assume it is compatible with Desktop and not Core as that module manifest either predates PowerShell Core or hasn't been updated since that member was added. We debated whether Unknown is better, but decided that Desktop (which the formatter shorthands to Desk) was the better solution.

As for the modules that ship with PS7, I agree that we should update those to have appropriate CompatiblePSEditions, however, some work on older versions of PowerShell than v5 so that manifest will make them incompatible. In fact, I believe all of the ones in the original screenshot were intended to work all the way to v3 so they can't add that member without breaking compatibility, but perhaps it's time to do that.

In the interim, perhaps what we can do is if the module is in $PSHOME, we can show as Core compatible, since we know that is the case even if the PSCompatibleEditions is empty.

[doctordns]

I think that the modules that ship with PS7 should be properly annotated.
Can't you bump the version number on those so that the 'old' module works with older versions of Windows Powershell but the newer one is for later versions?

[ThomasNieto]

The formatter can be updated to first check CompatiblePSEditions first then if not found check PSData for PSEdition_Desktop and PSEdition_Core tags. This allows for module authors to indicate what editions are supported without limiting the version to PS5.1+. This recommendation is on this page: https://docs.microsoft.com/en-us/powershell/scripting/gallery/concepts/module-psedition-support?view=powershell-7

This script block below updates the formatter to leverage Tags when CompatiblePSEditions is not specified. If none are found it defaults to Desktop.

$result = [System.Collections.ArrayList]::new()
$editions = $_.CompatiblePSEditions

if (-not $editions)
{
    if ($_.PrivateData -and ($_.PrivateData.PSData.Tags -contains 'PSEdition_Desktop' -or $_.PrivateData.PSData.Tags -contains 'PSEdition_Core'))
    {
        $editions = @(($_.PrivateData.PSData.Tags | Where-Object {$_ -like 'PSEdition_*'}) -replace 'PSEdition_', '')
    }
    else {
        $editions = @('Desktop')
    }
}

foreach ($edition in $editions)
{
    $result += $edition.Substring(0, 4)
}

($result | Sort-Object) -join ','

For example today Pester is marked as Desktop only but using this formatter it shows Core and Desktop like the module author indented.

# Current
PS C:\> Get-Module -ListAvailable | Where-Object Name -eq pester | Select-Object -First 1


    Directory: C:\Program Files\WindowsPowerShell\Modules

ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Script     4.9.0                 Pester                              Desk      {Describe, Context, It, Should…}


# New
PS C:\> Get-Module -ListAvailable | Where-Object Name -eq pester | Select-Object -First 1


    Directory: C:\Program Files\WindowsPowerShell\Modules

ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Script     4.9.0                 Pester                              Core,Desk {Describe, Context, It, Should…}

Modules with compatible PowerShell Editions - PowerShell

[iSazonov]

@ThomasNieto I believe your comment should be moved to #7856.

[he852100]

Should add auto tags when publishing or force publishers to add tags.
PSEdition_Desktop``PSEdition_core``PSEdition_Windows``PSEdition_Linux``PSEdition_macos
It is quite difficult for users to retrieve compatible modules ，Linux and Windows are up to 80% incompatible!

[SteveL-MSFT]

@doctordns the modules shipped with PS7 are the same modules you would install from PSGallery. So it doesn't make sense to bump the version number and modify the manifest to indicate compatibility and break use cases for downlevel PowerShells. I think the solution here is on the client side and not in the module.

[iSazonov]

@SteveL-MSFT I think modules _from the PowerShell repo_ (like Utility) can be fixed in manifests.