PSResourceGet
PSResourceGet copied to clipboard
PowerShell
[Feature Request]: Ability to configure PSRepository on a system-wide level
It would be great if there was a way to register a PSRepository on the system-wide level, so that if configured once, it would work for all the users on a particular system.
Expected Behavior
Register-PSRepository should have a -Scope parameter added, to control whether a particular PSRepository needs to be registered for just the current user of for the whole system (similar to the behavior of Execution Policy). It would also be great to have an extra scope option, that would register PSRepository just for the current session (like mentioned in PowerShell/PowerShellGet#65)
Apart from the Register-PSRepository, the remaining set of the *-PSRepository cmdlets should also have the -Scope parameter. Set-PSRepository and Unregister-PSRepository cmdlets should require admin privileges to work against system-wide PSRepository settings and 'Get-PSRepository' cmdlet should not require admin privileges at all.
Current Behavior
Currently Register-PSRepository only works for the user that is executing the cmdlet.
Context
Having an ability to register PSRepository on a system-wide level would allow us to pre-configure our internal Repositories in the Virtual Machine templates, thus making the provisioning process much simpler.
Additionally, that would simplify maintaining existing PSRepository configurations in a consistent fashion across all our systems.
Your Environment
PS C:\Users> $PSVersionTable
Name Value
---- -----
PSVersion 5.1.15063.726
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.15063.726
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
PS C:\Users>
PS C:\Users> Get-Module
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Manifest 3.1.0.0 Microsoft.PowerShell.Utility {Add-Member, Add-Type, Clear-Variable, Compare-Object...}
Script 1.2 PSReadline {Get-PSReadlineKeyHandler, Get-PSReadlineOption, Remove-PS...
PS C:\Users>
PS C:\Users> Get-Module -ListAvailable PowerShellGet,PackageManagement
Directory: C:\Program Files\WindowsPowerShell\Modules
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 1.1.7.0 PackageManagement {Find-Package, Get-Package, Get-PackageProvider, Get-Packa...
Script 1.1.1.0 PackageManagement {Find-Package, Get-Package, Get-PackageProvider, Get-Packa...
Binary 1.0.0.1 PackageManagement {Find-Package, Get-Package, Get-PackageProvider, Get-Packa...
Script 1.6.0 PowerShellGet {Install-Module, Find-Module, Save-Module, Update-Module...}
Script 1.1.2.0 PowerShellGet {Install-Module, Find-Module, Save-Module, Update-Module...}
Script 1.0.0.1 PowerShellGet {Install-Module, Find-Module, Save-Module, Update-Module...}
Directory: C:\Program Files (x86)\WindowsPowerShell\Modules
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Binary 1.0.0.1 PackageManagement {Find-Package, Get-Package, Get-PackageProvider, Get-Packa...
Script 1.0.0.1 PowerShellGet {Install-Module, Find-Module, Save-Module, Update-Module...}
PS C:\Users>
PS C:\Users> Get-PackageProvider
Name Version DynamicOptions
---- ------- --------------
msi 3.0.0.0 AdditionalArguments
msu 3.0.0.0
NuGet 2.8.5.210 Destination, ExcludeVersion, Scope, SkipDependencies, Headers, FilterOnTag...
PowerShellGet 1.6.0.0 PackageManagementProvider, Type, Scope, AllowClobber, SkipPublisherCheck, ...
Programs 3.0.0.0 IncludeWindowsInstaller, IncludeSystemComponent
PS C:\Users> Get-PackageProvider -ListAvailable
Name Version DynamicOptions
---- ------- --------------
msi 3.0.0.0 AdditionalArguments
msu 3.0.0.0
nuget 2.8.5.208
NuGet 2.8.5.210 Destination, ExcludeVersion, Scope, SkipDependencies, Headers, FilterOnTag...
NuGetProvider 2.8.5.208
PowerShellGet 1.6.0.0 PackageManagementProvider, Type, Scope, AllowClobber, SkipPublisherCheck, ...
PowerShellGet 1.1.2.0
PowerShellGet 1.0.0.1
Programs 3.0.0.0 IncludeWindowsInstaller, IncludeSystemComponent
I also support this request.
If an admin runs Install-Module -Scope AllUsers on a system, a different admin has to first register this repository in order to call Update-Module. Every time I touch a system and want to install or update a module, I first have to check to see if the repository is registered. Even if we fully automate the onboarding of that system, I still have to register a repository by hand.
What I do now is just include the repository registration logic in any and all scripts that install modules.
Windows PowerShell team, any guidance on where the "AllUsers" repositories configuration file would live? I see 2 options:
$script:ProgramFilesPSPathas this is where the AllUsers Modules are installed$script:PSGetProgramDataPathseems like the place for this configuration but might not work for "AllUsers" on Linux/OSX
@bradleywehmeie, thanks for looking into this feature request.
Yes, $script:PSGetProgramDataPath is the right place for this configuration file.
For non-Windows platforms, please update the $script:PSGetProgramDataPath to '/usr/local/share/powershellget'.
Current:
$script:PSGetProgramDataPath = Microsoft.PowerShell.Management\Join-Path -Path ([System.Management.Automation.Platform]::SelectProductNameForDirectory('CONFIG')) -ChildPath 'PowerShellGet'
Expected:
$script:PSGetProgramDataPath = '/usr/local/share/powershellget'
Main Question
How do we expect Unregister-PSRepository to function when the Scope parameter is omitted? Should it be allowed to modify the AllUsers scope if the Scope is omitted OR should the Scope be required anytime the AllUsers scope is being modified?
Example:
Register-PSRepository -Name Test -Scope AllUsers ...
# Should this be allowed?
Unregister-PSRepository -Name Test
# Or should we require the Scope?
Unregister-PSRepository -Name Test -Scope AllUsers
Additional Context
With either implementation, the Set/Unregister-PSRepository cmdlets work as you would expect but I ran into a limitation with the Unregister-PackageSource cmdlet and pipelining. The value for Scope is not pipelined to the Unregister-PackageSource cmdlet so there are occasions where it will produce the incorrect result when attempting to work on the AllUsers scope.
For example:
Register-PSRepository -Name Test -Scope AllUsers ...
Get-PackageSource -Name Test -Scope AllUsers | Unregister-PackageSource
If we are strict about requiring the AllUsers to be specified, this will result in a Not Found error because no scope will end up being passed to Remove-PackageSource so it will assume "CurrentUser" scope. If we aren't strict, then Remove-PackageSource won't assume a scope and will find the Test PackageSource and remove it.
In both implementations if the PackageSource exists in both the CurrentUser and AllUsers (a case which is possible), Get-PackageSource -Name Test -Scope AllUsers | Unregister-PackageSource will remove the wrong PackageSource. It will find Test in the CurrentUsers scope and remove it from there instead of the AllUsers scope which was pipelined. For this reason maybe this additional context is a moot point and we should simply state that using *-PackageSource for AllUsers scope is not recommended/supported.
@bradleywehmeier If a user is trying to unregister an AllUsers scoped repository, it is required to ensure that user has the admin privileges similar to the Uninstall and Update cmdlets.
As part of this enhancement, are you allowing the duplicate PSRepository names? I think we should allow this as the users and admin may give the same name for the psrepositories. if not, can we follow the same design as the Uninstall and Update cmdlets where -Scope parameter is not required on Unregister-PSRepository.
If we are allowing the duplicate psrepository names
- Add
Scopeoptional parameter on Unregister-PSRepository cmdlet - Admin privileges check is also required for the AllUsers scoped psrepositories
- Scope parameter is optional for the AllUsers scoped psrepositories
- If Scope parameter is not specified, Unregister-PSRepository cmdlet first checks if the given name is registered for the currentuser scope and unregisters it.
Above is also applicable to the Set-PSRepository cmdlet.
We need to add -Scope optional parameter in PowerShellGet provider dynamic options for the sources at https://github.com/PowerShell/PowerShellGet/blob/development/PowerShellGet/public/providerfunctions/Get-DynamicOptions.ps1#L31 similar to https://github.com/PowerShell/PowerShellGet/blob/development/PowerShellGet/public/providerfunctions/Get-DynamicOptions.ps1#L44 For more details, please take a look at the ScriptSourceLocation dynamic option implementation in PowerShellGet provider functions.
For the pipeline operations with scope, it is required to specify -Provider PowerShellGet like below
Get-PackageSource -Name Test -Provider PowerShellGet -Scope AllUsers | Unregister-PackageSource
@bmanikm Yes admin is required for modifications to AllUsers Scope. Dynamic Parameters have been taken care of.
Duplicate Repository names have to be supported because there is no way to avoid a situation where an admin defines an AllUsers repo that overlaps with a setting that a user has already set. In this case the user will get the instance they defined (CurrentUser scope) not the AllUsers scope.
“Scope parameter is optional for the AllUsers scoped psrepositories” answers my real question here.
With the rest having been taken care of look for a pull request in the next couple of days after I look it over one last time.
Also please consider validating the install and update scenarios with the duplicate psrepository names as the source locations can be different.
Regarding the case of duplicate PSRepository names with different source locations:
- For Install, the repository that will be used is the CurrentUser scoped PSRepository. This is the same PSRepository that is shown in Get-PSRepository in this case so it is consistent.
- For Update, I'm assuming the desired behavior is to use the same source location that was originally used to install. Is that assumption correct?
The name overlap does cause problems for Update. It wants to use the PSRepository source location defined in CurrentUser regardless of what source location was used for the install.
The more I think about it, I'm not sure if my assumption was correct.
- On one hand, downloading updates from the same location you downloaded makes perfect sense.
- On the other hand, the primary mechanism that is used to reference a particular PSRepository is the Name and we allow situations where the source location is allowed to change and PowerShellGet continues to function with the new location.
When there are duplicate PSRepository names and one is chosen to be the "winner", I can also make an argument to treat that scenario in the same way we treat the PSRepository source location having been changed and using the source location from the "winner".
There are other rough edges with PowerShellGet like the current behavior of using a "CurrentUser" PSRepository to install "AllUsers" modules. If those are not causing issues, then maybe this confusion will also be negligible.
One alternative would be to Prefix the AllUsers scoped PSRepositories so that name collisions were not possible. I originally avoided that so that PackageManagement cmdlets (e.g. Register-PackageSource) and PowerShellGet cmdlets (e.g. Register-PSRepository) would have the same/similar parameters. If that's not something that matters since most people will be using the PowerShellGet cmdlets, I can spend some time implementing that approach to see if it has fewer issues.
Thanks all for your input on this. I appreciate the effort in helping me get this right.
@bradleywehmeier thanks for looking into this feature!
Some thoughts
- By default, Get-PSRepository cmdlet should list all the registered repositories in both scopes (CurrentUser and AllUsers). We need to add the Scope property/column in the Get-PSRepository output format.
- Duplicate repository names should not be allowed in a single scope.
- In case of duplicate repository names, CurrentUser scope gets precedence over AllUsers scope.
- During the Install operation, we also need to add a property called RepositoryScope in the PSRepositoryItemInfo in PSGetModuleInfo.xml/[ScriptName]_InstalledScriptInfo.xml file so that update operation picks the correct repository name and scope. This follows the current update functionality.
I also support this. I had a very confusing few hours the other day, trying to configure a proxy PowerShellGet package source through DSC. Since DSC runs as the system user, I couldn't see the repositories it was registering. I am now trying to figure out how to configure the proxy repository for all users. (Does anyone have any good solutions to that?)
Agreed this is much needed feature. I'm trying to use the PackageManagement DSC resource to configure our internal/proxy nexus repository as part of an OS deployment but is only applied under the NT Autority\System account. The modules install fine from the internal repo as part of the DSC config, however normal users still see the default PSGallery repo meaning they cannot pull approved and custom internal modules when required.
I just want to chime in that this causes problems using Jenkins automation as well. Jenkins agents sometimes run under system or certain service account logins and i have no good way to configure the psrepository for them.
+1 for this feature. We've want to move to using PowerShellGet exclusively for module distribution but we get constant requests for assistance with setting up the right repos which is slowing down adoption. This feature would solve that.
@SteveL-MSFT As a quick observation, this is actually a OneGet issue and not a PowerShellGet issue.
I created the following issue in OneGet to ALIGN the two projects. https://github.com/OneGet/oneget/issues/468
As Program Manager for PowerShell Core, you can facilitate, advocate for, and resource a solution to this problem!
I can not use Register-PackageSource (or psrepository) by my service build account that has no local logon permissions. So how do I need to use all this package management mess? Should I use another solutions?
@SydneyhSmith any chance this can be added to 3.0? This is a huge missing feature in a multi-user environment.
Any updates on this? Our job scheduling tools uses temporary user profiles so full automation of things that utilize that tool is not possible unless I use @KevinMarquette's solution, which I'd like to avoid.
Hello,
Is there any update on this topic ? This is a a much needed feature for me as my configuration manager runs as system, I cannot register PSRepositories / install modules
Also plus 1. Definitely needed for enterprises trying to run private repositories.
Thanks all! We'll definitely prioritize this scenario since it's been a popular request
Tracking this feature work in https://github.com/PowerShell/PowerShellGet/issues/616
+1, looking forward to being able to set this and remove a fair bit of workaround code :)
