Get-Variable already available error when installing

[aloysiustany]

Hi,

I am getting the following error when installing Octopus-Cmdlets.

PackageManagement\Install-Package : A command with name 'Get-Variable' is already available on this system. This module 'Octopus-Cmdlets' may override the existing commands. If you still want to install this module 'Octopus-Cmdlets', use -AllowClobber parameter. At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1772 char:21

• ... $null = PackageManagement\Install-Package @PSBoundParameters

• 
  + CategoryInfo          : InvalidOperation: (Microsoft.Power....InstallPackage:InstallPackage) [Ins
  tall-Package], Exception
  + FullyQualifiedErrorId : CommandAlreadyAvailable,Validate-ModuleCommandAlreadyAvailable,Microsoft.
  PowerShell.PackageManagement.Cmdlets.InstallPackage

[indented-automation]

This also affects profile scripts which use Get-Variable / Remove-Variable. The prefix implementation in PowerShell is pretty flakey, what you've written should work.

This bug appears to be fixed in PowerShell 6 (alpha 18). However, it is present in 5.1 which is going to be as much as can be expected in most places.

Would you consider hard-coding the prefix?

[Swoogan]

Are you able to override it when importing?

Import-Module [-Global] [-Prefix <String>]

I'm reluctant to hard code it because that would also limit people's options when there is a clash.

[indented-automation]

It's the auto-loader that's doing it unfortunately, so while the prefix can be changed it doesn't affect the problem. My profile script uses Remove-Variable for other things and it's trigger load of this module (ignoring the prefix). The command I'm attempting then fails, apparently because it's triggered the autoloader and now can't find Remove-Variable. Awesome work, huh?

The same problem exhibits with installation. It sees *-Variable, ignores the prefix you've added, and whines that it needs to be allowed to replace commands (so will only install using Install-Module octopus-cmdlets -AllowClobber).

It's frustrating, the problem is not present under PowerShell 6 (even as far back as alpha 13), I can install perfectly happily there and it doesn't complain about a need to clobber. 6 is in beta now, arguably it won't be too long before it's released.

Anyway, I'll work around it, I can appreciate why you might not want to change it. If the module is not in $env:PSMODULEPATH the auto-loader doesn't get to play and cause this problem. I'll embed it in the DSC resources I planned to write around it, they'll just incorporate the module at build time (as you would with nuget restore).

PS good work on the module and thank you for sharing it. You don't often see things so well written.

On 12 July 2017 at 19:50, Colin Svingen notifications@github.com wrote:

Are you able to override it when importing?

Import-Module [-Global] [-Prefix ]

I'm reluctant to hard code it because that would also limit people's options when there is a clash.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Swoogan/Octopus-Cmdlets/issues/8#issuecomment-314862399, or mute the thread https://github.com/notifications/unsubscribe-auth/AMO6DhMY8wRdJfOziOu359WKZbqQ0HwUks5sNRVlgaJpZM4M2vww .

[Swoogan]

What is the "autoloader"? Is there some way to blacklist this module from it and then manually invoke Import-Module from your profile?

[rpresser]

Is there any progress on this? The error happens while doing Install-Module, not just while doing Import-Module, so I'm not sure how a prefix will help.

[Swoogan]

Hello. It turns out this is a known bug with PowerShell: https://github.com/PowerShell/PowerShell/issues/2590

You can read an excellent description of the problem by another module author: https://pkisharp.github.io/ACMESharp-docs/Why-AllowClobber.html

For the time being, I recommend using the -allowClobber flag when installing and the default prefix of Octo will be added when importing the module (unless overridden by the -Prefix flag)