Repository navigation
Uninstall-Module: add ability to uninstall dependent modules #87
Description
Activity
From Ilya (@iSazonov) on March 21, 2017 9:35
We have related Issue PowerShell/PowerShell#2505 "Reloading module does not reload submodules"
If we fix this we fix "upgrade multiple modules to their new version" too.@KrishnaV-MSFT this is needed by a customer, we can talk offline if you need more info.
It is important to understand that a module may be a dependency of more than one loaded module. In that scenario, removing only one of the depending modules should not remove the dependency module since it is still in use by at least one loaded module. If the goal here is to force a refresh of the entire module dependency tree, then this issue proposes the wrong solution. A better approach would be for Import-Module -Force to be transitive with respect to all dependencies. This is still an imperfect solution since the exports of the module will only be reimported into the new depending module's namespace.
It seems my comment was wrong - the Issue is about installing modules not importing.
Bruce Payette (@BrucePay) I should've clarified with my own take on how this should be implemented. We just need a command to remove dangling dependencies. Portage has
emerge --depclean, Yum haspackage-cleanupinyum-utils,apt-gethasapt-get autoremove.We need the same. Something like
Uninstall-Module -Orphanor something that alludes to a dangling/orphaned/unused dependency/module.This should be caculated based on whether or not a module installed by PowerShellGet was installed because it was a dependency of another module, or because a user explicitly installed it with
Install-Module.Reacted by bbomgardner, Jon Vaughan and Balázs OrbánA separate use case for consideration:
"Metapackages," like VMware.PowerCLI and Database, do not uninstall their friends when removed. In the VMware example, one has to know to
Get-Module vmware* -ListAvailable | Uninstall-Module -Force
And it gets uglier in the Database example, where there is no common naming convention among module dependencies.
I'd personally like to see this solved with an optional parameter on
Uninstall-Module.Thanks!
Reacted by Joey Aiello, bbomgardner and Leon VBrian Bunke (@brianbunke) yup, that's exactly the use case we're trying to fix here. In fact, VMware provided me this feedback already. 😄
Ah, sorry for the duplicate! Couldn't tell from the description.
I agree - this kind of stale dependency identification is pretty necessary for any package system.
From Dimitar Milov (@dmilov) on March 21, 2017 8:1
The use-case is to upgrade multiple modules to their new version. When there is a module with number of dependent modules Install-Module allows installing all dependent modules at once. If I need to upgrade the modules to new version with no willing to have multiple versions of certain module I'd expect to be able to uninstall module with all dependent modules at ones using Uninstall-Module.
Here is an example
Module A with version 1.0
Module B with version 1.0, which is required module in the A module's manifest
This call:
Install-Module -Name A -RequiredVersion 1.0
installs both A and B
When new versions of the above modules are published
Module A with version 2.0
Module B with version 2.0
I'd like to be able to
Uninstall-Module -Name A
Install-Module -Name A -RequiredVersion 2.0
and as a result to have installed only
A version 2.0
B version 2.0
Copied from original issue: PowerShell/PowerShell#3379