Module conflict in PowerShell during installation

[ahpooch]

Convert module Installation problem

While installing Convert module, I encountered a well known issue of commandlet name overlap with -AllowClobber. Initially, I needed the pwshEmojiExplorer module, which depends on the Convert module. The problem occurs in both PowerShell 5.1 and PowerShell 7, although the underlying reasons differ somewhat. Below, I will describe what these issues look like when installing the Convert module.

PSVersion: 7.5.4 (Core)

When trying to install module in Powershell 5.1 I got this error:

Install-Package: The following commands are already available on this system:'ConvertFrom-CliXml,ConvertTo-CliXml'. This module 'Convert' may override the existing commands. If you still want to install this module 'Convert', use -AllowClobber parameter.

The problem is cmdlets 'ConvertTo-CliXml' and 'ConvertFrom-CliXml' from Convert module. The same cmdlets or maybe just named equally already present at Microsoft.Powershell.Utility built-in system module but in binary form.

PSVersion: 5.1.26100.7019

When trying to install module in Powershell 5.1 I got this error:

PackageManagement\Install-Package : The following commands are already available on this system: "Get-Hash". This module "Convert" may override the existing commands. If you still want to install this module 'Convert', use -AllowClobber parameter.
C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1809 знак:21
+ ...          $null = PackageManagement\Install-Package @PSBoundParameters
+                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Exception
    + FullyQualifiedErrorId : CommandAlreadyAvailable,Validate-ModuleCommandAlreadyAvailable,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage

The problem is in Get-Hash Alias from Convert module.

Question

Given the above, I'd like to ask, @austoonz, what do you think: is it a good idea to remove the cmdlets 'ConvertTo-CliXml' and 'ConvertFrom-CliXml', as well as the alias 'Get-Hash' from the project? Or would a better solution be to rename the cmdlets so they don't conflict with the system cmdlets, for example, changing them to 'ConvertTo-CliXml2' and 'ConvertFrom-CliXml2'? Or perhaps you see another, better solution to this problem?

[austoonz]

Interesting. The CliXml ones are here as they don't exist in Windows PowerShell 5.1. I guess Microsoft added them to PowerShell 7 at some point. I'd like to keep them and not sure what name they should take. Unless I consider moving them to a new module and remove from this one.

Re Get-hash, can I ask which module that is clashing with?

I am re-writing the core of this module in Rust which will be a v2.0 release. That would be the time for some breaking changes if needed. Only concern is whether people use this on Windows PowerShell and want the CliXml conversion functions. Not sure if I could if-statement an Export-ModuleMember for those only in Windows... 🤔

[ahpooch]

Unfortunately, I could not determine which module uses the name Get-Hash; it is most likely an alias as well. I assumed it is an alias for the Microsoft.PowerShell.Utility module's cmdlet Get-FileHash, but I couldn't confirm this.

I briefly analyzed whether it is possible to implement a dynamic export for the 'ConvertTo-CliXml' and 'ConvertFrom-CliXml' cmdlets depending on the current PSVersion. As I understand, this could be achieved by describing the logic in the .psm1 file and removing the cmdlets from FunctionsToExport in the .psd1 file. However, this does not seem like an elegant solution to me. For example, I am not particularly fond of the idea that cmdlets with the same name would represent different and potentially differently functioning code in PowerShell 7 and PowerShell 5.1, as they would be imported from different sources. It seems better if there were a way to use the cmdlets from the Convert module's composition in different versions of PowerShell. And the simplest way to implement this without encountering a conflict is to rename these cmdlets.

I've made this changes in forked repository and after that I've been able to build It without warnings and manually imported it to use with pwshEmojiExplorer.

[austoonz]

Instead of what you suggested, I've been finalizing my plans to move the core of the module to Rust.

In doing so, I've published two -alpha prerelease modules to the PowerShell gallery. A new breaking change version of Convert that removes the Clixml functions and the Get-Hash alias, and a new ConvertClixml module that contains the two Clixml functions.

Find-Module -Name Convert -AllowPrerelease
Find-Module -Name ConvertClixml -AllowPrerelease

Feel free to play around with those and confirm whether they're a) resolving this issue for you, and perhaps b) working as you intend (given the major changes to the core of the module).

[mattcargile]

Would you be willing to add a if block for $PSEdition to only add the CliXml on Desktop? You can add it to the psd1 even.

Oh I see you have a new ConvertClixml module...that works too.

[austoonz]

I didn't want to use an if condition because then I can't just use the .psd1 to control the FunctionsToExport properties of the module.

And yes, separating seemed like the cleanest solution given the gap only exists for Windows PowerShell now. May end up moving those alpha modules to non-prerelease given (as expected) not many people pick those up and use them.

[mattcargile]

I didn't want to use an if condition because then I can't just use the .psd1 to control the FunctionsToExport properties of the module.

Well you add the if block inside the @(), right, inside the psd1 file? Is that what you are thinking?

[austoonz]

I didn't want that because places like the functions list on the PowerShell Gallery will not be accurate for all systems anymore; it will depend on which systems evaluated the manifest for what functions are part of the module.