In this blog post we are excited to share:

• PowerShellGet 3.0 preview 10 is now available on the PowerShell Gallery
• CompatPowerShellGet compatibility module is now publicly available on GitHub and PowerShell Gallery
• Our current thoughts on migrating to PowerShellGet 3.0

PowerShellGet 3.0 Preview Updates

PowerShellGet 3.0 preview 10 is now available on the PowerShell Gallery. This blog post will cover all of the feature updates since we last published a blog post ( preview 6). These versions include completed functionality for updating PSResources, input-object support for installing PSResources as well as several bug fixes. To install the latest version of the module, open any console any run:

Install-Module PowerShellGet -AllowPrerelease -Force -Repository PSGallery -SkipPublisherCheck

What’s new in the preview releases

New Features

• Completed functionality for Update-PSResource
• Input-Object parameter for Install-PSResource
• Add ‘sudo’ check for admin privileges in Unix in Install-PSResource
• Adds DSCResources

Bug Fixes

• Improved experience when loading module for different frameworks
• Bug fix for assembly loading error in Publish-PSResource
• Allow for relative paths when registering a PSRepository
• Improved error handling for Install-PSResource and Update-PSResource
• Remove prerelease tag from module version directory
• Fix error getting thrown from paths with incorrectly formatted module versions
• Fix bug with retrieving installed scripts in Get-PSResource
• Fix bug with AllUsers scope in Windows in Install-PSResource
• Fix bug with Uninstall-PSResource sometimes not fully uninstalling
• Change installed file paths to contain original version number instead of normalized version
• Fix bug related to finding dependencies that do not have a specified version in Find-PSResource
• Fix bug related to parsing ‘RequiredModules’ in .psd1 in Publish-PSResource
• Improve error handling for when repository in Publish-PSResource does not exist
• Fix for unix paths in Get-PSResource, Install-PSResource, and Uninstall-PSResource
• Add debugging statements for Get-PSResource and Install-PSResource
• Fix bug related to paths in Uninstall-PSResource
• Bug fix for -ModuleName (used with -Version) in Find-PSResource returning incorrect resource type
• Make repositories unique by name
• Add tab completion for -Name parameter in Get-PSResource, Set-PSResource, and Unregister-PSResource
• Remove credential argument from Register-PSResourceRepository
• Change returned version type from ‘NuGet.Version’ to ‘System.Version’
• Have Install output verbose message on successful installation (error for unsuccessful installation)
• Ensure that not passing credentials does not throw an error if searching through multiple repositories
• Remove attempt to remove loaded assemblies in psm1

What’s Next

We plan to have a minimum of three more releases as we approach general availability (GA) of the 3.0 module. Our next planned release, preview 11 will address these issues. Once we are feature complete we will have the release candidate (RC) version. If no high risk or high impact issues are reported after this, we will ship that version of the module (plus any small bug fixes) as the GA version of PowerShellGet 3.0.

Once we reach this important milestone, we will re-evaluate next steps for the module by assessing the flow of incoming issues and re-evaluating issues marked with the “vNext” milestone in the repository. After we reach GA of this module, we will continue to invest in making PowerShell’s package management experience great.

Availability in PowerShell

We plan to begin shipping PowerShellGet 3.0 in PowerShell 7.2 previews. In these releases of PowerShell 7.2 we will include 2 related modules:

• PowerShellGet 3.0
• CompatPowerShellGet

Introducing CompatPowerShellGet

CompatPowerShellGet is a compatibility module that allows use of PowerShellGet 2.x (and below) cmdlet syntax with PowerShellGet 3.0 (and newer) functionality by making a best effort mapping between the cmdlet interfaces of both versions of the module. For example, if a user has the CompatPowerShellGet module installed and runs the command: Install-Module PowerShellGet -MinimumVersion 1 -MaximumVersion 2 -AllowPrerelease The CompatPowerShellGet module will get auto loaded into the PowerShell Session and will map the command to PowerShellGet 3.0 syntax: Install-PSResource PowerShellGet -Version "[1,2]" -Prerelease" The command will then be executed by the PowerShellGet 3.0 implementation. The user will also get a warning to update their script to the new cmdlet interface: WARNING: The cmdlet 'Install-Module' is deprecated, please use 'Install-PSResource’.

This module is designed so that users will not need to immediately update their scripts in order to update to the latest version of PowerShell or to begin taking advantage of the performance improvements already available in PowerShellGet 3.0. We still do recommend that authors begin making the minimal changes required to update their scripts to the new cmdlet interface.

This compatibility module is designed so that it takes precedence over legacy versions of PowerShellGet. If you have this compatibility module installed and would not like it to be used, you can remove it from the PowerShell session using the Remove-Module command.

Please note that this flow is only possible if the user has both the CompatPowerShellGet module installed and the PowerShellGet 3.0 preview module installed. Once PowerShellGet 3.0 is generally available it will be a dependency of CompatPowerShellGet.

Please also note that this compatibility module will not be called if you use fully qualified cmdlets. For example, if you use PowerShellGet\Install-Module this will call a legacy version of PowerShellGet. If this is a common scenario for you, and will be a barrier to migrating to PowerShellGet 3.0 we would appreciate that feedback in our GitHub repository

Goals of Migration to PowerShellGet 3.0

While creating a migration plan for PowerShellGet users we had the following goals in mind.

• Have the quality of PowerShellGet 3.0 be so high that users want to migrate their scripts
• Reduce friction for users to take immediate advantage of improvements in PowerShellGet 3.0
• Not break any scripts in the short term for user who adopt the latest available version of PowerShell
• Create a low friction migration path for script and module owners
• Have a single, widely used version of PowerShellGet (for supportability, and improvement reasons)

Look forward to the next blog post (coordinated with our RC release of PowerShellGet 3.0) detailing the feature and performance improvements in PowerShellGet 3.0. We hope this post will give insight into why we believe users will have the best possible experience by migrating to PowerShellGet 3.0.

Migration Timeline

Beginning with PowerShell 7.2 preview 1 release we will ship the latest versions of the PowerShellGet 3.0 and CompatPowerShellGet modules.

As we continue to track usage and feedback around the compatibility layer, as well as the PowerShellGet 3.0 module, we hope to move towards a long term goal of only shipping the latest version of PowerShellGet in new versions of PowerShell.

Feedback and Support

At this stage in our development of the module user feedback is critical. For support or feedback on PowerShellGet please open an issue in this GitHub repository. For support or feedback on the CompatPowerShellGet module, or the migration plan please open an issue in this GitHub Repository.

Sydney Smith
PowerShell Team