Repository navigation
Expand the syntax for Module-Qualified commands to allow you to specify a specific version as well #8949
Description
When writing scripts that have potentially clashing Cmdlet/function/alias names it is recommended to use the Full Module-Qualified name like below
Microsoft.PowerShell.Core\ForEach-ObjectWhilst this is an extremely useful feature, this has an issue with it only working with either the currently loaded version or the latest version of the module specifiec and as such this is perhaps a lingering aspect of the language that was never updated when v5 came out which supported Side by Side versions
Therefore I think it would be great if the following syntax would be able to be accepted and correctly parsed
PowerShellGet:1.6.0\Find-ModuleThis breaks down to
<moduleName>:<moduleVersion>\<CommandName>
The potential although limited use case for this is within scripts that have dependencies on modules that have interesting & weird differences between module versions
You can already load multiple versions of a module into the same session so this would enable script/module authors another method for diagnosing accidental breaking changes in a more typical side by side manner within the same session
Activity
kilasuit commentedon May 21, 2020
PowerShellGet is a bad example to use but if you had pinned versions in the PSD1 you could get round this with some not great coding like this
The problem would be then the 1.0.0.1 would be calling the latest version of PackageManagement not the one required by that version, which affects many other modules as well.
Having this built in with a simpler syntax like
<moduleName>:<moduleVersion>\<CommandName>would help in defensive coding strategies where you really want to be explicit of what you are running but would allow for side by side module version use especially thinking Major Version module changes.kilasuit commentedon May 21, 2020
As Fred on the PS Community call mentioned (I think Friedrich Weinmann (@FriedrichWeinmann) ) pointed out you could even drop into the older module and call it like so
though this isn't well known and would only really work for defensive coding if Nested Modules were used instead of global session modules
Edit - this would also be viable for using v3 and v2 of PowerShellGet in side by side mode but breaks using the simpler
PowerShellGet\Find-Modulesyntax that many know and is easier to readkilasuit commentedon Dec 3, 2022
The key benefit for this is that for mission critical use cases you can then properly plan a move up from a version of a module that you are reliant on, whilst also potentially being able to call a newer or older version of a specific function within that module.
It's a edge case for sure, but one that I feel is needed for ensuring orgs don't always get hammered by a huge change that they weren't quite ready for.
kilasuit commentedon Aug 21, 2023
Another benefit for this - though may make sense as another smaller work item would be that error messages could show in the invocation info (where available) the following minor adjustment especially as Command Path may not include the version number in there at all
This is how it works today
InvocationInfo : MyCommand : Install-Package ScriptLineNumber : 13069 OffsetInLine : 20 HistoryId : 36 ScriptName : /usr/local/microsoft/powershell/7/Modules/PowerShellGet/PSModule.psm1 Line : $sid = PackageManagement\Install-Package @PSBoundParameters PositionMessage : At /usr/local/microsoft/powershell/7/Modules/PowerShellGet/PSModule.psm1:13069 char:20 + … $sid = PackageManagement\Install-Package @PSBoundParameters + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PSScriptRoot : /usr/local/microsoft/powershell/7/Modules/PowerShellGet PSCommandPath : /usr/local/microsoft/powershell/7/Modules/PowerShellGet/PSModule.psm1 InvocationName : PackageManagement\Install-Package CommandOrigin : Internalbut a minor change to
InvocationName : PackageManagement\Install-Packageto be sayInvocationName : PackageManagement['1.4.8.1']\Install-Packagemicrosoft-github-policy-service commentedon Feb 17, 2024
This issue has not had any activity in 6 months, if there is no further activity in 7 days, the issue will be closed automatically.
Activity in this case refers only to comments on the issue. If the issue is closed and you are the author, you can re-open the issue using the button below. Please add more information to be considered during retriage. If you are not the author but the issue is impacting you after it has been closed, please submit a new issue with updated details and a link to this issue and the original.
sdwheeler commentedon May 22, 2024
The Interactive WG reviewed this and feels that this needs to be decided by the Language WG.