Repository navigation
Make Microsoft.PowerShell.Platform a system module #625
Description
I believe we should add the Microsoft.PowerShell.Platform to the built-in modules.
This would give us $IsWindows, $IsLinux, $IsOSX, and $IsCore as global variables for both full and core PowerShell. We are now programming against these in the Pester tests. This would also give us a set module to add further platform-specific PowerShell functionality (I'm surprised we haven't already done this).
Doing this would enable me to remove its import statement from the default profile, and from the CI scripts.
Activity
andyleejordan commentedon Mar 5, 2016
This issue was sparked by #623.
vors commentedon Mar 7, 2016
Just hit this problem
andyleejordan commentedon Mar 7, 2016
If we do not add the Platform module to the built-in modules, then we must always override the
PSModulePathbecause it's being inherited from the environment on Windows, and does not contain our modules folder. I am for adding it as a built-in.andyleejordan commentedon Mar 8, 2016
Work-around for now is
$env:PsModulePath="$pwd/bin/Modules".PowerShell Core always expects to have this path, but we'd still want to inherit a set
PsModulePath. Would it be appropriate to check the path, and if this folder (the built-ins folder) is missing, add it?JamesWTruher commentedon Mar 8, 2016
hmmmm - this is only true if you're in the PowerShell directory (where build.sh is) - also, is there any case sensitivity about the environment variable? An alternative approach is to put
export PSMODULEPATH=$HOME/PowerShell/bin/Modulesin your BASH profile
andyleejordan commentedon Mar 8, 2016
James Truher (@JamesWTruher) This is not an issue on Linux, this is an issue on Windows.
andyleejordan commentedon Mar 9, 2016
Paul Allen (@paulcallen) Hit this too with remoting tests. The platform module must become a built-in for things to work "as expected" with cross-platform PowerShell script development.
I'll get on this.
andyleejordan commentedon Mar 11, 2016
Resolved this in #646.