Ref: #59
Blocked by: #988
Moving the discussion of upgrade-the-world functionality to a separate issue. It doesn't make sense to start this discussion until there's a dependency resolver added.
it doesnt make sense to add an upgrade_all command until there is a curated package repository
Following the discussion from #6081, I've successfully created a plugin system for pip that seems to work fine with existing packages.
Here is the branch I'm working on (see - plugin.py)
search_plugin_scripts()
function looks for executables prefixed with PIP_PLUGIN_SCRIPT_PREFIX
(currently "pip-plugin-"
). So it catches executables like pip-plugin-compile
.--help
. Auto-complete also works as of now.This architecture allows for plugins that are independent of the actual package, which I think is quite nice.
It also solves the major recurring problem related to cross-virtualenv execution. Any plugins written with this architecture can be made so that they only need to be installed once on the global python, and then used from within a virtualenv.
I have also added a --disable-plugins
switch.
I've created a small package that will generate a plugin. It allows exposing an existing python CLI as a pip plugin.
Also, Here is a proof of concept that contains some popular packages wrapped as plugins. (including $ pip upgrade
!)
It's obviously not ready to be merged. I need to run the tests (and write new ones).
There is no documentation either.
@devxpy Discussion about a plugin API is off topic for this issue.
There's prior discussion at https://github.com/pypa/pip/issues/3999. If you want to make some points about why we should have one, especially ones not already made there, please make them there or in a new issue referencing that.
Sorry about the confusion - I hadn't noticed that in #6081 the discussion had shifted to talk about a plugin API and the MVP was regarding an upgrade command, not a plugin API.
https://github.com/nschloe/pipdate does something like a makeshift global upgrade. Be aware though that upgrading can break things.
@nschloe
https://github.com/nschloe/pipdate does something like a makeshift global upgrade. Be aware though that upgrading can break things.
You're absolutely right, it can break things ! :+1:
Here is my attempt of an "almost" robust solution - pipupgrade. Also handles packages that break change.
As this ticket is blocked by the development of the dependency resolver (#988), I thought I would mention here that the team is looking for help from the community to move forward on that subject.
We need to better understand the circumstances under which the new resolver fails, so are asking for pip users with complex dependencies to:
--unstable-feature=resolver
)You can find more information and more detailed instructions here
Most helpful comment
Following the discussion from #6081, I've successfully created a plugin system for pip that seems to work fine with existing packages.
Here is the branch I'm working on (see - plugin.py)
How it works?
search_plugin_scripts()
function looks for executables prefixed withPIP_PLUGIN_SCRIPT_PREFIX
(currently"pip-plugin-"
). So it catches executables likepip-plugin-compile
.--help
. Auto-complete also works as of now.This architecture allows for plugins that are independent of the actual package, which I think is quite nice.
It also solves the major recurring problem related to cross-virtualenv execution. Any plugins written with this architecture can be made so that they only need to be installed once on the global python, and then used from within a virtualenv.
I have also added a
--disable-plugins
switch.How to actually write plugins?
I've created a small package that will generate a plugin. It allows exposing an existing python CLI as a pip plugin.
Also, Here is a proof of concept that contains some popular packages wrapped as plugins. (including
$ pip upgrade
!)It's obviously not ready to be merged. I need to run the tests (and write new ones).
There is no documentation either.