New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uninstall-Module: add ability to uninstall dependent modules #114

Open
joeyaiello opened this Issue Apr 11, 2017 · 10 comments

Comments

Projects
None yet
8 participants
@joeyaiello
Member

joeyaiello commented Apr 11, 2017

From @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

@joeyaiello

This comment has been minimized.

Member

joeyaiello commented Apr 11, 2017

From @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

This comment has been minimized.

Member

joeyaiello commented Apr 11, 2017

@KrishnaV-MSFT this is needed by a customer, we can talk offline if you need more info.

@BrucePay

This comment has been minimized.

Member

BrucePay commented 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

This comment has been minimized.

iSazonov commented Apr 12, 2017

It seems my comment was wrong - the Issue is about installing modules not importing.

@joeyaiello

This comment has been minimized.

Member

joeyaiello commented Apr 12, 2017

@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.

@brianbunke

This comment has been minimized.

Contributor

brianbunke commented 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

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!

@joeyaiello

This comment has been minimized.

Member

joeyaiello commented Jun 6, 2017

@brianbunke yup, that's exactly the use case we're trying to fix here. In fact, VMware provided me this feedback already. 😄

@brianbunke

This comment has been minimized.

Contributor

brianbunke commented Jun 7, 2017

Ah, sorry for the duplicate! Couldn't tell from the description.

@gyorgynadaban

This comment has been minimized.

gyorgynadaban commented Mar 6, 2018

Any update on this case? It'd sure come in handy with AzureRM's 50 submodules...

@bbomgardner

This comment has been minimized.

bbomgardner commented May 23, 2018

I agree - this kind of stale dependency identification is pretty necessary for any package system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment