Extend #Requires -Modules to include a Repository option #28140

Activity

1. Ryan Yates (kilasuit)

   added

   Issue-Enhancementthe issue is more of a feature request than a bugthe issue is more of a feature request than a bug

   Needs-TriageThe issue is new and needs to be triaged by a work group.The issue is new and needs to be triaged by a work group.

   on Oct 5, 2026
2. kilasuit commented on Oct 5, 2026

   

   Ryan Yates (kilasuit)

   on Oct 5, 2026

   CollaboratorAuthor

   More actions

   I feel that this would need to be wrapped in an Experimental Feature as this is quite a change in experience.

   I did look to see if this was already raised but could not find on looking.
3. rhubarb-geek-nz commented on Oct 5, 2026

   

   rhubarb-geek-nz

   on Oct 5, 2026

   More actions

   The problem I see is that PSGallery does not identify the repository. The names of repositories are locally configured values which then identify the URL of the nuget repository. I could have the repository PSGallery configured to be anything.
   If my module comes from a third party repository, I have no idea what you have that configured as.
   It is merely convention that PSGallery is initially configured.

   PS> Get-PSResourceRepository  
   
   Name      Uri                                      Trusted Priority IsAllowedByPolicy
   ----      ---                                      ------- -------- -----------------
   PSGallery https://www.powershellgallery.com/api/v2 False   50       True
   

   👍React with 👍1Reacted by Michael Klement
4. rhubarb-geek-nz commented on Oct 6, 2026

   

   rhubarb-geek-nz

   on Oct 6, 2026

   More actions

   • fall back to installing the explicit version listed

   Are you saying that the requires statement will perform an installation?

   The current documentation only says that it will import an available module.

   Installation and execution are currently separate activities. If your script is part of a module then your dependency should be part of your manifest. If you have an independent script and the requirements can't be met without further installation then it should fail.
5. MartinGC94 commented on Oct 10, 2026

   

   MartinGC94

   on Oct 10, 2026

   Contributor

   More actions

   I think the concept of automatically installing missing modules is fine, but I think the idea of specifying the module repository is wrong. For one it's a setting that the end user (or the system admins) should control, rather than some third party script author who doesn't know the environment where it will run.
   Maybe I've removed the PSGallery, and replaced it with an internal repository that mirrors popular (and approved) modules. Should the feature fail, even if my configured repository has a copy of the required module? I don't think so.

   Secondly, this idea would make the feature opt-in from the script author side, which in practice means the feature wouldn't see much use, especially when you consider the next point.

   Finally in most cases the specified repository is going to be "PSGallery", so specifying the repository is just going to be pointless clutter.

   I think a global option configured by the end user would be better (Preference variable, or config file value). #Requires -Modules would then act according to that value (Stop = Current behavior where it throws an error if it can't find the module. Prompt = Ask if the module should be downloaded. Automatic = Automatically download the module.
6. rhubarb-geek-nz commented on Oct 10, 2026

   

   rhubarb-geek-nz

   on Oct 10, 2026

   More actions

   I think the concept of automatically installing missing modules is fine,

   I've looked for equivalence

   1. Python does not install modules that are not installed but referenced by import, you get a ModuleNotFoundError.
   2. When building Java with maven or dotnet and with nuget, dependences will be downloaded, but that is only into a repository for building. They don't become executables on the path.

   I certainly want to stay in control of what is installed in my environments and I treat PSGallery as untrusted, Trusted=$false so even when manually installing I have to further confirm that this is what I want.

   If this feature is implemented, it should definitely be opt-in from the side of the script runner, and should not override the Trusted state of any registered repository.
7. kilasuit commented on Oct 11, 2026

   

   Ryan Yates (kilasuit)

   on Oct 11, 2026

   CollaboratorAuthor

   More actions

   Are you saying that the requires statement will perform an installation?

   Yes, I felt that was clear enough from within the Technical Implementation & the additional comment about likely gating this behind an Experimental Feature.

   Apologies if it wasn't from those I've updated the initial comment, including to be clear that this isn't just about installs from PSGallery, which was a simple example, my bad for not adding a non-PSGallery example in there initially. It could be MAR, a Azure Packages Feed or any of the other different types of repositories that are supported by PSResourceGet that are out there today, or new ones in future.

   The problem I see is that PSGallery does not identify the repository. The names of repositories are locally configured values which then identify the URL of the nuget repository.

   Actually, the Name is the Identifier of the repository.
   The URI (not URL as it could be a fileshare based repository so would be file:\ & not https:) is just the endpoint and

   Yes, also if/when this gets added the documentation would need updating.

   If you have an independent script and the requirements can't be met without further installation then it should fail.

   This I disagree with, but feel there is a way, which by adding this as a enhancement, gated behind an experimental feature, would enable that to happen & do so in a secure manner meeting the below

   If this feature is implemented, it should definitely be opt-in from the side of the script runner, and should not override the Trusted state of any registered repository.

   Now, we already have workarounds for in scripts where you will see code like this to perform this exact task.

   $moduleName = 'MySecretProject13'
   if (-not (Get-Module $moduleName -ListAvailable)) {
   Install-PSResource $moduleName -TrustRepository -Repository kilasuitSecretProjects
   }
    
   Import-Module $moduleName

   or

   $moduleName = 'MySecretProject27'
   $moduleVersion = [Version]'1.0.0.1'
   if (-not (Get-Module $moduleName -ListAvailable).Version -gt $moduleVersion ) {
   Install-PSResource $moduleName -TrustRepository -Repository kilasuitSecretProjects
   }
    
   Import-Module $moduleName

   or similar where they make use of RequiresModules.psd1 with Install-PSResource - which not all people are using due to still using Install-Module.

   We also have the New-PSScriptFileInfo cmdlet in PSResourceGet, that exposes some details like ExternalModuleDependencies that overlap with #Requires Statements but isn't an engine level check and doesn't stop someone having a script try to execute and fail nicely. Using the Get-PSScriptInfo cmdlet will give you

   Also, a PowerShell Script

   1. doesn't need to have a PSScriptFileInfo section, lots don't.
   2. If they do they can also make use of the Requires Statements, even though lots don't.
   3. For orgs that want proper documented scripts with their dependencies, there isn't an either or statement here, they both can be used together.
   4. They could also make use of RequiresModules.psd1 too & a check system similar to the above code

   in most cases the specified repository is going to be "PSGallery", so specifying the repository is just going to be pointless clutter.

   This I have to disagree with, but that's a preference of whether you are explicit/implicit in how you author scripts.

   I think a global option configured by the end user would be better (Preference variable, or config file value). #Requires -Modules would then act according to that value (Stop = Current behavior where it throws an error if it can't find the module. Prompt = Ask if the module should be downloaded. Automatic = Automatically download the module.

   There's no reason why we cannot have global option like this as well as an option that script authors can control. Particularly as this could be for shared scripts inside a team inside a large org that uses their own package host alongside org ones and/or public ones. Or even things like from a Support Case/Previews where there is a requirement for authenticated user access to a 3rd-parties module repository for the script and all of it's dependencies. Something that I've had to deal with in the past.
8. Ryan Yates (kilasuit)

   added

   WG-Securitysecurity related areas such as JEAsecurity related areas such as JEA

   WG-NeedsReviewNeeds a review by the labeled Working GroupNeeds a review by the labeled Working Group

   on Oct 11, 2026
9. kilasuit commented on Oct 11, 2026

   

   Ryan Yates (kilasuit)

   on Oct 11, 2026

   CollaboratorAuthor

   More actions

   I'm going to mark this for the Security WG to discuss first as they have to be ok with this just as much as the Engine Group would need to be for this to be implemented.

   Also happy for needing to raise an RFC for this & get feedback that way.