Add pip plugin to support upgrade/uninstall all packages.

[NariyasuHeseri]

[NoahGorny]

@NariyasuHeseri LGTM, I'll let @cornfeedhobo chime in here and them merge

[cornfeedhobo]

@NariyasuHeseri Thank you again for your contributions! Moving the conversation here since the issue is not code.

I use this command to upgrade outdated pip packages installed by the system package manager to user's home. If --user is provided, only those installed by pip install --user will be upgraded. This may be the desired behaviour for some users, but since pip will also install dependencies to user's home, which may in fact upgrade system-installed packages, the option --user does not actually guarantee "only user-installed packages are upgraded".

I understand that this is your workflow, but I don't support codifying a personalized pattern that needs in-depth explanation in such a widely used project. You say it best:

This may be the desired behaviour for some users

Saying this implicitly admits that this is an opinionated addition that could trip some users up.

Addressing this pattern directly; I believe most of the python community uses virtual environments to isolate their package installs and that is much safer. Unfortunately I don't have time to setup a VM to prove this today, but I'm pretty sure this would also break system-installed packages that depend on specific python versions. E.g. I have a GUI right now that is broken by an upgraded cryptography library with a changed API.

I'll leave this to @NoahGorny and/or @nwinkler, but my vote is that this is too personal and should not be included in bash-it.

Edit: @NariyasuHeseri I'm not sure if you've seen in the docs, but you can also place personal plugins like these into ~/.bash_it/custom and they won't be touched during upgrades.

[NariyasuHeseri]

@NariyasuHeseri Thank you again for your contributions! Moving the conversation here since the issue is not code.

I use this command to upgrade outdated pip packages installed by the system package manager to user's home. If --user is provided, only those installed by pip install --user will be upgraded. This may be the desired behaviour for some users, but since pip will also install dependencies to user's home, which may in fact upgrade system-installed packages, the option --user does not actually guarantee "only user-installed packages are upgraded".

I understand that this is your workflow, but I don't support codifying a personalized pattern that needs in-depth explanation in such a widely used project. You say it best:

This may be the desired behaviour for some users

Saying this implicitly admits that this is an opinionated addition that could trip some users up.

Addressing this pattern directly; I believe most of the python community uses virtual environments to isolate their package installs and that is much safer. Unfortunately I don't have time to setup a VM to prove this today, but I'm pretty sure this would also break system-installed packages that depend on specific python versions. E.g. I have a GUI right now that is broken by an upgraded cryptography library with a changed API.

I'll leave this to @NoahGorny and/or @nwinkler, but my vote is that this is too personal and should not be included in bash-it.

Edit: @NariyasuHeseri I'm not sure if you've seen in the docs, but you can also place personal plugins like these into ~/.bash_it/custom and they won't be touched during upgrades.

Thanks for your reply. For Python projects we create a VM and use requirements.txt or Pipfile to specify dependencies, in which case system-installed packages are irrelevant and this command is not used anyway. However, from time to time, it is helpful, for example, to launch iPython and do some computation with numpy or graph-drawing using matplotlib, which uses global packages installed in the user's home. Thus a simple command to upgrade them all is likely helpful. Upgrading packages in user's home should be safe as long as it is safe to use pip to install any Python package to user's home. If this is not the case, one has to stick to system's package manager thus pip should not be used anyway.