Powershell: PSEdition module field should not say "Desk" when no CompatiblePSEditions field is given in the manifest

[rjmholt]

Currently if a module is written and has no manifest or its manifest has no CompatiblePSEditions field, Get-Module -ListAvailable will describe it as having the PSEdition value as Desk:

> gmo -list
Directory: C:\Program Files\PowerShell\Modules


ModuleType Version    Name                                PSEdition ExportedCommands
---------- -------    ----                                --------- ----------------
Script     0.9.0      platyPS                             Desk      {New-MarkdownHelp, Get-MarkdownMetadata, New-External...
Script     0.7.3      posh-git                            Desk      {Invoke-NullCoalescing, Add-PoshGitToProfile, Get-Pro...

If our goal is to accurately reflect the manifest (or lack thereof), we should have a separate case for it, like -:

    Directory: C:\Program Files\PowerShell\Modules


ModuleType Version    Name                                PSEdition ExportedCommands
---------- -------    ----                                --------- ----------------
Script     0.9.0      platyPS                             -         {New-MarkdownHelp, Get-MarkdownMetadata, New-External...
Script     0.7.3      posh-git                            -         {Invoke-NullCoalescing, Add-PoshGitToProfile, Get-Pro...

The change would be easily made here:
https://github.com/PowerShell/PowerShell/blob/8a0abf459c31ce99d6ecc81ebb165179fe192d28/src/System.Management.Automation/FormatAndOutput/DefaultFormatters/PowerShellCore_format_ps1xml.cs#L1217-L1228

We can just insert a

if (-not $editions)
{
    return '-'
}

instead of the current $editions = @('Desktop').

[SteveL-MSFT]

I believe the original thinking from @HemantMahawar is that modules without a manifest or manifest without that property were designed and tested only against Windows PowerShell, so Desktop was implied.

[rjmholt]

See also https://github.com/PowerShell/PowerShell/issues/7643 for discussion.

@daxian-dbw and I originally discussed displaying the actual manifest contents vs its inferred value, and decided we should try to reflect the true contents of the manifest. But it also makes sense to display the compatibility here.

[rjmholt]

In particular see https://github.com/PowerShell/PowerShell/issues/7643#issuecomment-416509068

[SteveL-MSFT]

@PowerShell/powershell-committee reviewed this. The original proposal was that if CompatiblePSEditions is empty, it is only interpreted as Desktop if the module is in the system32 path. Modules in ProgramFiles (or anywhere else) should just be empty.

[KirkMunro]

Related: #10931

[SteveL-MSFT]

Replied in the related issue, but repeating here. It seems that for modules that are in $PSHOME, we can safely assume that they are Core compatible and show them as such.

[ThomasNieto]

Created PR #11950 to solve this by updating the PSEdition column in the Module table format to check PrivateData.PSData.Tags for PSEdition_Desktop and PSEdition_Core if CompatiblePSEditions is not defined. For shipped modules if CompatiblePSEditions or tags are not for a module in $PSHOME it will add Core and if the module is in Windows in-box it will add Desktop.

This allows module authors to indicate compatible PSEditions without limiting module compatibility to 5.1+ by using CompatiblePSEditions.

[thorstenbutz]

I applogize, but this behaviour does not make any sense:
5 out of 10 built-in modules in PS 7 on linux (!) are tagged as "Desk", even the new ThreadJob module is missing a CompatiblePSEditions entry.
You should definitely remove those lines of code simply guessing ...

[joeyaiello]

So to summarize:

• modules with a blank CompatiblePSEditions in system32 should show Desktop
• modules with a blank CompatiblePSEditions in $PSHome should show Core
  
  
  
  • modules in $PSHome should never have manifests explicitly set to only Desktop
  
  
• modules with a blank CompatiblePSEditions anywhere else should stay blank

[rjmholt]

I can see arguments for wanting CompatiblePSEditions on the PSModuleInfo to reflect the manifest as closely as possible, but I can see the reasoning here as well. I'm happy to accept it if users agree.