Repository navigation
Current module manifest schema is not adequate to properly support cross-platform modules #5541
Description
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.
Activity
lzybkr commentedon Nov 25, 2017
I originally proposed allowing variables like
$IsLinuxin the module manifest so you could write:Untested, but I think all that is needed is to add to this list.
mklement0 commentedon Mar 8, 2018
A complementary aspect is how to restrict a module to an edition / a (set of) platform(s):
From what I can tell, setting
CompatiblePSEditionsto 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 commentedon Apr 17, 2019
I would like to contribute and make a PR for this issue :
Anything else ?
vexx32 commentedon Apr 17, 2019
That sounds like a good start, go for it! 😄
fMichaleczek commentedon May 1, 2019
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 commentedon Nov 16, 2023
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 commentedon Nov 16, 2023
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 commentedon Nov 16, 2023
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 commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.