Begin thinking about PowerShellGet 3.0 support

[briantist]

SUMMARY

This issue is intended to track and discuss PowerShellGet 3.0:

• https://devblogs.microsoft.com/powershell/powershellget-3-0-preview-1/
• https://github.com/PowerShell/PowerShell-RFC/pull/237/files#diff-661062766ee198277a334922a903752e

It's pretty major update, with tons of good, but breaking, changes.

New action items coming out of this can probably be broken off into their own issues.

ISSUE TYPE

• Feature Idea

COMPONENT NAME

Affected modules:

• win_psrepository
• win_psrepository_info
• win_psmodule
• win_psmodule_info
• win_psscript
• win_psscript_info

ADDITIONAL INFORMATION

Not everything is complete or decided yet, but reading over the changes, I think there's enough there to start thinking about how to support it.

I think the first thing would probably be to update the existing module's code and documentation to explicitly specify that the required version of PowerShellGet be <3.0.0. They are considering adding aliases (probably functions since the parameters don't match up) for the old cmdlet names but its not certain and it looks like it'll be opt in, so I don't think we can rely on a smooth transition there.

Looking forward, to actually support it I see 2 possible paths at the moment:

1) The existing modules test for which version is available and provide a seamless(ish) experience.

Pros:

• Existing playbooks work (probably)

Cons:

• Not all parameters to the underlying commands line up or are congruent anymore. This may make for an awkward option set.
• Complexity and maintenance will be a hassle.
• Testing is already complicated for some these, and will be much worse.

2) A new set of Ansible modules following their new naming conventions (like win_psresource).

Pros:

• Vastly simpler maintenance and testing. The changes they are making also simplify the set of modules so these would be less complicated than the originals even.
• A simpler and easier to understand option set.
• A clear delineation between the old and new when it comes to both PowerShellGet version and which Ansible module you pick.
• Allows for Ansible playbook/role authors to handle support and fallback for different PowerShellGet versions themselves by using the existing win_psmodule_info to determine installed PowerShellGet version and then branch on which other modules to use (see Other thoughts section though)
• A clearer path for eventually (if ever) deprecating the older modules.

Cons:

• Existing playbooks won't work in situations where only PowerShellGet 3.0+ is available.

3) ~ x) Other suggestions welcome

Other Thoughts

win_psmodule_info is a bit of a special case because it returns information on PowerShell modules whether they were installed via repository or not, and it includes repository info. This one might need some cross compatibility.

For the case of determining what version of PowerShellGet is installed, I wonder if it might make sense to add something to the setup module for Windows that returns a limited set of PS module versions; maybe somewhere it can be specified which modules are important enough to be returned in fact gathering. Repository info isn't that important so it'd be a simplified operation of Get-Module -ListAvailable -Name <names>.

In either of the 1) or 2) options above, a module util might make sense for some common tasks to be pushed to a module_util. In the case of 1) it would probably handle all the heavy abstraction between versions. In 2) it would be smaller and more manageable.

[jhawkesworth]

How about a win_psget_info module instead of adding to setup? I am not a big user of powershell get at the moment. Personally I think option 2 would a fine way forward but I appreciate others will be far more affected by this change than I am.

[briantist]

How about a win_psget_info module instead of adding to setup?

If it's going to be a separate module then win_psmodule_info(#62) should work for that; but it might need a little work to be compatible with psget 2 & 3 in therms of the extra info it retrieves.

My thinking with setup was avoiding an extra module call for users who need the info and are already gathering facts. And also since the "extra" info gotten by win_psmodule_info is not needed for the simpler use case of determining the version. Maybe adding an option to that module that doesn't include any psget info in the output would make it more appropriate for that use case since it could work well before psget 3 compatibility would be added in 🤔.

Anyway since I think it makes sense to generalize the setup idea into "there's a core set of modules we want some cursory info about in facts" it should probably be its own proposal, I just happened to think of it in the context of psget. Maybe Pester would be another of the default set of modules in that set, would need some thought.

I am not a big user of powershell get at the moment. Personally I think option 2 would a fine way forward but I appreciate others will be far more affected by this change than I am.

I'm clearly more in favor of 2 at the moment, but eager to hear other perspectives.

[jborean93]

My thoughts would be to go 1 of 2 ways

1. Modify the existing modules to only return a small subset of options and have the compatibility code inside the module to translate v2 and v3 results to the common output, or
2. Just document, once we know more about it, that the output is determined by the PSGet version installed

I don't think separate modules are a good idea here, personally I think 1 would be the way to go. Trying to unify a problematic/changing interface to ease end user utilisation should be a pretty big priority but unfortunately it would mean having a more complicated module with more maintenance required.