You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Uninstall-Module: add ability to uninstall dependent modules #87
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
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.
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.
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 has package-cleanup in yum-utils, apt-get has apt-get autoremove.
We need the same. Something like Uninstall-Module -Orphan or 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án
Activity
joeyaiello commentedon Apr 11, 2017
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.
joeyaiello commentedon Apr 11, 2017
@KrishnaV-MSFT this is needed by a customer, we can talk offline if you need more info.
BrucePay commentedon Apr 11, 2017
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.
iSazonov commentedon Apr 12, 2017
It seems my comment was wrong - the Issue is about installing modules not importing.
joeyaiello commentedon Apr 12, 2017
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.brianbunke commentedon May 12, 2017
A 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
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!
joeyaiello commentedon Jun 6, 2017
Brian Bunke (@brianbunke) yup, that's exactly the use case we're trying to fix here. In fact, VMware provided me this feedback already. 😄
brianbunke commentedon Jun 7, 2017
Ah, sorry for the duplicate! Couldn't tell from the description.
bbomgardner commentedon May 23, 2018
I agree - this kind of stale dependency identification is pretty necessary for any package system.