[Feature Request] Allow rollback on failed upgrade

[TSlivede]

What's the problem this feature will solve?

On upgrade, if the installation (or uninstallation) of a package fails, the system can currently be left in an corrupted state. (Executing pip install --ugrade pip on Windows (see #1299) leaves at least my system in a state where pip no longer works... - I actually don't know if the behavior is different for installation problems of other packages, though I suspect it's not.)

Describe the solution you'd like

Instead of deleting files of the old package versions, move them to a temporary place, and only delete them, after the package installation succeeds. If something fails, move the old files back, such that the old package version continues to work.

If I did pip install --ugrade pip on Windows it would still fail, but I wouldn't have to reinstall python and could just issue the correct command python -m pip install --ugrade pip.

Alternative Solutions

I could of course manually copy (back up) my whole python installation before each execution of pip, but I am probably as likely to forget this, as I am likely to forget to use python -m pip install --ugrade pip instead of just pip install --ugrade pip.

Additional context

I don't know much about the pip internals, so I don't rally know how hard it would be to implement this.

[uranusjr]

The pip install pip case is special, because if that fails, pip would already be corrupted, and there’s nothing left to perform the rollback. So the proposal is not likely to work.

I believe there is already an issue somewhere proposing to block this usage entirely (i.e. you cannot execute this command at all, there for there’s no need to implement a rollback). That would be the correct approach IMO.

[TSlivede]

@uranusjr

I believe there is already an issue somewhere proposing to block this usage entirely (i.e. you cannot execute this command at all, there for there’s no need to implement a rollback). That would be the correct approach IMO.

I actually linked the issue (it's #1299), but after reading through that thread (and some others), I do now understand, that it is surprisingly difficult to fix that. And from what I understood from the comments, it doesn't seem likely, that something will be done about that. (#1299 (comment) explains, why it is difficult to detect this case...)

The pip install pip case is special, because if that fails, pip would already be corrupted, and there’s nothing left to perform the rollback

Well, as currently the upgrade is implemented as uninstall old, then install new (or did I misinterpret the output of python -m pip install --ugrade pip?), there still seems to be something running that is performing the installation of the new version after the old one was deleted. If that "something" could also do the rollback, that should be enough (If I understand these things correctly...)

[uranusjr]

I think what I was thinking was #7567. #1299 has existed for a long time, and the solution is known to be buggy.

Edit: Uh no, I don’t think that’s the one either (although it’s related and should be done). I seem to recall @pradyunsg made a comment somewhere that the detection logic is wrong…? Or maybe I was imagining things.

[TSlivede]

Ah ok, although I read quite some time about the problem, I didn't find that thread. If what's written there ("Since pip already moves them to a temporary directory during uninstallation (so it can rollback on e.g. upgrade failures)," is true, it would be fine by me if you closed this issue. (As what I suggested is then already implemented)

[pradyunsg]

Ahoy!

When we changed the logic for uninstall to use AdjecentDirectory on Windows, it seems that our logic for detecting "pip install" modifying pip and suggesting python -m pip on Windows broke.

I don't have a Windows machine to experiment with this, and diagnose further.

[uranusjr]

I think this is covered by #7567.