Closed msftrubengu closed 8 months ago
This scenario should be already working by setting PSModulePath
env var on dsc
process.
PowerShell
process, started by dsc
will inherit it and will use that to lookup PS modules with DSC resources.
Just remember that PSDesiredStateConfiguration
module should also be accessible by the value of PSModulePath
env var that you're setting.
WG discussed this and there is a scenario where the user might have a config that uses both WinPS and PS7 so it makes sense to have the same named property for both the WindowsPowerShellGroup and PowerShellGroup:
properties:
psmodulepath: $env:PSModulePath;$env:LOCALAPPDATA\Microsoft\WinGet\Configuration\Modules
resources: ...
In this example, the PSModulePath
env var is clobbered within the group resource (thus PSDSC is still found by the default env var). The string value would be PS syntax and expanded within the group resource. We expect other language resources (ie, Python) would use their language syntax.
Summary of the new feature / enhancement
By default, winget configure installs PowerShell modules under %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules. This was done to avoid conflicts when OneDrive moves the user's profile to their OneDrive's profile while winget configure is executing. If the modules are stored in the winget location powershellgroup.resource.ps1 won't be able to find the modules.
Proposed technical implementation details (optional)
A new property in the PowerShellGroup with additionalModulePaths