Custom `psmodulepath` not supported in `Microsoft.Adapter/PowerShell`

[Gijsreyn]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Summary

I was trying out the new Microsoft.Adapter/PowerShell and use the psmodulepath to add custom modules, but it doesn't seem to work. In the old way, it's possible to do something like:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: Custom module 
    type: Microsoft.DSC/PowerShell
    properties:
      psmodulepath: C:\CustomModules;<existingModulePaths>
      resources:
        - name: PowerShell 7 Preview
          type: Microsoft.WinGet.DSC/WinGetPackage    # Direct resource type
          properties:
            Id: Microsoft.PowerShell.Preview
            Ensure: Present

Then, in the new way, I would expect something like:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: PowerShell 7 Preview
    type: Microsoft.WinGet.DSC/WinGetPackage    
    metadata:
      Microsoft.DSC:
        requireAdapter: Microsoft.Adapter/PowerShell 
    # psmodulepath: C:\CustomModules
    properties:
      Id: Microsoft.PowerShell.Preview
      Ensure: Present
      psmodulepath: C:\CustomModules;<existingModulePaths>

But that's going to fail with: Exception: The property 'psmodulepath' cannot be found on this object. Verify that the property exists and can be set.

Steps to reproduce

Run above examples with dsc config get

Expected behavior

Expect to be able to use custom module paths.

Actual behavior

Not able to use custom module path

Error details

Environment data

Name                           Value
----                           -----
PSVersion                      7.5.4
PSEdition                      Core
GitCommitId                    7.5.4
OS                             Microsoft Windows 10.0.26200
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Version

dsc 3.2.0-preview.11

Visuals

No response

[ThomasNieto]

Should we allow dsc to specify custom module paths or require users to set that in powershell env var?

[Gijsreyn]

I'm fine with setting it in PowerShell's environment variable, but it should be clear to the user whenever moving to the new adapters, it isn't possible to set that property anymore. It's also covered in the Pester tests.

[SteveL-MSFT]

properties would get sent to the actual PS based resource. So there's a conflict if that resource happens to have a property called psmodulepath. Alternatively, this could be something sent to the adapter via metadata. However, is there an actual use case for this outside of tests?

[Gijsreyn]

@SteveL-MSFT - the use case came mainly from the WinGet team: #285.

[SteveL-MSFT]

Hmm, forgot about that. I guess this could be a good use case for metadata

[michaeltlombardi]

I think this was the original pitch for passing metadata to a resource - here it controls how the adapter behaves rather than what the resource enforces.

I can't seem to find an issue for it, but I remember a discussion (WG, maybe?) about breaking up discovery and invocation for adapters. But thinking more about this, I'm wondering if we would have defined adapters as resources at all if extensions had already existed, especially in the new model where we want to always send a single resource to the adapter for invocation and not process nested configurations.

Which relates back to #1080, where it would be very coherent to pass options to an extension once instead of on every use. I think the same problem exists for adapters.

I'm not firmly recommending that we pivot adapters again, but it's worth considering before the next stable release whether the new model for adapters is more coherently represented as an extension and then we could solve extension options once and get configurable options for adapters at the same time without reverting to the metadata behavior, which can be very weird to structure, describe, and use.

[Gijsreyn]

Hmm, forgot about that. I guess this could be a good use case for metadata

That's where you have the GitHub history for ;)