Current module manifest schema is not adequate to properly support cross-platform modules

[rkeithhill]

It is not going to be uncommon for module authors to want to provide slightly different functionality on different operating systems e.g. the module provides 30 commands, two of which only work on Windows PowerShell. Right now, there is no good way to declare "conditional" module exports in the manifest where the condition is the OS platform.

In fact, even PowerShellVersion is problematic if you design your module to load into both Windows PowerShell and PowerShell Core. Which PowerShell version does that refer to? Windows PowerShell? PowerShell Core? What if at some point, on PS Core I require 6.1.0? Does that mean my module can't load into Windows PowerShell 5.x anymore - probably. But I may not be providing that functionality when I'm loaded into Windows PowerShell (runtime decision) so Win PS 5.1 should be allowed when loading into Windows PowerShell.

AFAICT all of these field's values may be conditional upon the OS platform and/or the PowerShell platform (Win or Core)

• PowerShellVersion
• PowerShellHostName / Version
• RequiredAssemblies
• RequiredModules
• ModuleList
• NestedModules
• FormatsToProcess
• ScriptsToProcess
• TypesToProcess
• ClrVersion
• DotNetFrameworkVersion
• AliasesToExport although CompatiblePSEditions might mitigate this one
• CmdletsToExport
• FunctionsToExport
• VariablesToExport
• Tags

In order to make any changes backwards compatible with existing Windows PowerShell instance, we could put all the conditional declarations in PrivateData. This implies that fields not in PrivateData inherently apply to Windows PowerShell when module is loaded by Windows PowerShell. PowerShell Core could be modified to process the conditional fields in PrivateData. What might those look like? Maybe this?

    PrivateData = @{
        PSManifestEx = @{
            PowerShellVersion = "6.1.0" # fields at this level apply to all OS platforms for PS Core
            Linux = @{
                RequiredModules = @(...)
                CmdletsToExport = @(...)
            }
            MacOS = @{
                RequiredModules = @(...)
                CmdletsToExport = @(...)
            }
            Windows = @{ # this is for PowerShell Core on Windows
                RequiredModules = @(...)
                CmdletsToExport = @(...)
            }
        }

This doesn't take into account Nano server which I don't have enough experience with to take it into account. Anyway, this is just something to get the conversation started.

Long term, this approach seems less than ideal - burying so much important metadata under PrivateData.

[lzybkr]

I originally proposed allowing variables like $IsLinux in the module manifest so you could write:

ExportedCmdlets = @(
    'Get-Thing'
    if ($IsLinux) { 'Get-LinuxThing' }
)

Untested, but I think all that is needed is to add to this list.

[mklement0]

A complementary aspect is how to restrict a module to an edition / a (set of) platform(s):

• From what I can tell, setting CompatiblePSEditions to one edition isn't being enforced at module import time.

• It seems that there is no key at all to limit support to a given (set of) platform(s).

(Note that edition support and platform support are independent dimensions; conceivably, modules can run on both editions while requiring Windows as the platform.
Conversely, though, limiting support to non-Windows platforms implies the Core edition.)

[fMichaleczek]

I would like to contribute and make a PR for this issue :

• Add IsLinux, IsMacOS and IsWindows to ModuleCmdletBase.cs#L448
• Write pester tests

Anything else ?

[vexx32]

That sounds like a good start, go for it! 😄

[fMichaleczek]

I would like to add PSVersionTable too, someone against that ?
Architecture is still a missing information in PSVersionTable but can be added later #8047

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.