We are excited to announce that an update to our preview of PowerShellGet 3.0 is now available on the PowerShell Gallery!
This release includes support for PSResourceRepository credential persistence, as well as support for RequiredResourceFiles for Install.
How to Install PowerShellGet 3.0 Preview 14
Prerequisites
Please ensure that you have the latest (non-prerelease) version of PowerShellGet and PackageManagement installed. To check the version you currently have installed run the command Get-InstalledModule PowerShellGet, PackageManagement
The latest version of PowerShellGet is 2.2.5, and the latest version of PackageManagement is 1.4.7. To install the latest versions of these modules run the following: Install-Module PowerShellGet -Force -AllowClobber
Installing the Preview
To install this preview release side-by-side with your existing PowerShellGet version, open any PowerShell console and run: Install-Module PowerShellGet -Force -AllowPrerelease
What to expect in this update
The key features and bug fixes are listed below, for the full list of changes please refer to the Changelog.
Features of this release
- -Scope parameter for Get-PSResource and Uninstall-PSResource
- -CredentialInfo parameter for Register-PSResourceRepository
- Clt+C support for Find-PSResource
- -RequiredResource parameter for Install-PSResource
- Publish-PSResource Script publishing support
- -Prerelease support for Uninstall-PSResource
- Install-PSResource -RequiredResourceFile parameter for psd1 and json
- -RequiredResource parameter Install-PSResource
Bug Fixes
- RequiredModules support for publishing
- Register-PSResourceRepository -Repositories parameter renamed to -Repository
- Rename PSResourceInfo’s PrereleaseLabel property to match Prerelease column displayed
- Parameter consistency: change url to uri
Using Credential Persistence
This community contributed feature allows you to provide information about where a credential is stored when registering the PSResourceRepository using a -CredentialInfo parameter. This parameter takes a PSCredentialInfo object which takes a vault name and secret name. The secret will then be pulled to authenticate to the Repository on Find and Install calls. This feature takes advantage of SecretManagement, for more information on SecretManagement refer the documentation.
Requirements
- Microsoft.PowerShell.SecretManagement
- Any vault extension registered (for this example I will use Microsoft.PowerShell.SecretStore)
- A repository to connect to (for this example I will use Artifactory)
Getting started
For this example I am going to be using SecretStore to store my credentials for an Artifactory repository. This can be repeated with any SecretManagement extension vault, and with any repository. First, I need to make sure I have a SecretManagement vault set up, with my credential stored. Currently this feature only supports the PSCredential secret type, however, we have an issue to track support for other types.
PS C:Users > Get-SecretInfo
Name Type VaultName
---- ---- ---------
jFrogCred PSCredential SecretStore
Then I can create a PSCredentialInfo object to pass into my PSResourceRepository registration, to create this I pass in the name of the vault and the name of the secret.
$credentialInfo = New-Object Microsoft.PowerShell.PowerShellGet.UtilClasses.PSCredentialInfo ("SecretStore", "jfrogCred")
Now I am ready to register the PSResourceRepository, I will pass in a friendly name, a URI for the repository, and the CredentialInfo. I also use the -Trusted switch because I will be controlling what gets published to the repository.
Register-PSResourceRepository -Name artifactory `
-URI " https://<name>.jfrog.io/artifactory/api/nuget/v3/<Repository-Name>
-Trusted `
-CredentialInfo $credentialInfo
Now I can run Get-PSResourceRepository to see my registered repositories
PS C:Users > Get-PSResourceRepository
Name Uri Trusted Priority
---- --- ------- --------
artifactory https://<name>.jfrog.io/artifactory/api/nuget/v3/<Repository-Name> True 50
PSGallery https://www.powershellgallery.com/api/v2 False 50
If the repository is empty you are going to want to begin by publishing to it. I have saved my API key for publishing to the repository in my SecretStore.
Publish-PSResource -Path .Get-Hello -Repository artifactory -ApiKey (Get-Secret jfrogPublish)
Now I can find and install PSResources from my repository without needing to provide a credential at each call.
PS C:Users> Find-PSResource -Name Get-Hello -Repository artifactory
Name Version Prerelease Repository Description
---- ------- ---------- ---------- -----------
Get-Hello 0.0.2.0 artifactory test module
PS C:Users> Install-PSResource Get-Hello
Using Required Resources
Install-PSResource can accept a path to a psd1 or json file (using -RequiredResourceFile), or a hashtable or json (using -RequiredResource).
Getting Started
The -RequiredResource parameter can take either a hashtable or a json format string. The following example shows how to format these inputs.
Install-PSResource -RequiredResource @{
'Configuration' = @{
version = '[1.3.1,2.0]'
repository = 'PSGallery'
}
'Pester' = @{
version = '[4.4.2,4.7.0]'
repository = 'PSGallery'
allowPrerelease = $true
}
}
In this case the modules named “Configuration”, and “Pester” will be installed. The json format will be the same as if this hashtable is passed to ConvertTo-Json:
"{
'Pester': {
'allowPrerelease': true,
'version': '[4.4.2,4.7.0]',
'repository': 'PSGallery'
},
'Configuration': {
'version': '[1.3.1,2.0]',
'repository': 'PSGallery'
}
}"
Declared dependencies are searched and installed using the same trust algorithm as for Install-PSResource.
The -RequiredResourceFile parameter can accept either a psd1 or a json file. The psd1 should use the same format as the hashtable above, the json file should use the same format as the json sting above.
Features to Expect in Coming Preview Releases
This module is not yet feature complete. Below is a list of features which you can expect to see in the next preview release.
New-ScriptFileInfocmdletTest-ScriptFileInfocmdletUpdate-ScriptFileInfocmdletUpdate-ModuleManifestcmdlet-AuthenticodeCheckparameter switch for Save, Install, Update
Using the CompatPowerShellGet module
CompatPowerShellGet is a compatibility module that allows use of PowerShellGet 2.x (and below) cmdlet syntax with PowerShellGet 3.0 (and above) functionality by making a best effort mapping between the cmdlet interfaces of both versions of the module. New PowerShell scripts that only leverage PowerShellGet v3 cmdlets do not need to use this compatibility 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 autoloaded 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 PowerShellGetInstall-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.
How to Track the Development of this Module
GitHub is the best place to track the bugs/feature requests related to this module. We have used a combination of projects and labels on our GitHub repo to track issues for this upcoming release. We are using the label Resolved-3.0 to label issues that we plan to release at some point before we release the module as GA (generally available).
To track issues/features for the next release, please refer to this GitHub project.
How to Give feedback and Get Support
We cannot overstate how critical user feedback is at this stage in the development of the module. Feedback from preview releases help inform design decisions without incurring a breaking change once generally available and used in production.
In order to help us to make key decisions around the behavior of the module please give us feedback by opening issues in our GitHub repository.
Sydney Smith
PowerShell Team
The post PowerShellGet 3.0 Preview 14 appeared first on PowerShell Team.
