Add option to cause non-zero exit code if pip install caused conflicting packages

[mitchhentges]

What's the problem this feature will solve?

I'm writing tooling around pip, and I would like it to "fail fast" when an environment has conflicting packages.

Describe the solution you'd like

In #7744, it's discussed how it's currently not feasible to block a pip install from happening if will cause conflicts.

However, in today's behaviour, pip install does an internal equivalent of pip check at the end to check for conflicts.
My feature request here is for that internal pip check to return a non-zero exit code if conflicts are detected.

This allows scripts that run pip install <package> --return-exit-code-if-conflicts-are-caused-please to stop immediately after conflicts are caused.

Alternative Solutions

I'm currently running pip check after each pip install, which is essentially doubling the amount of "conflict-checking" that's happening.

Additional context

Thanks!

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pfmoore]

Can you describe the specific use cases and benefits you expect to get from this? The cost of a pip check is pretty minor (certainly compared to the cost of an install) and all you are really saving here is the extra command.

In addition, we'd be changing the meaning of the return code - at present I believe that a non-zero return code means that pip didn't install anything, and left the environment unchanged. I'm pretty sure there will be people who rely on that fact, so we either break their workflows, or (as in your example) we add a flag that changes the meaning of the return code, which would cause confusion. And you'd still need to distinguish between "install failed, no change" and "install succeeded, but pip check failed", so you'd need a different return code.

If we were designing pip from scratch, this might be a reasonable feature to have, but given where we are now, I'm not sure it's worth it. But as I say, if the uses you're thinking of are compelling, that might change my mind.

[mitchhentges]

Those are good points, and I'm afraid that my reasons aren't particularly compelling.
I'd say that I have three benefits I'd be seeing from this:

1. Running pip check takes a nontrivial amount of time (~100ms for Python start, then at least another ~100ms for pip check itself). However, you're right that this is going to be running after a pip install, which takes far longer.
2. I'd like how my project wouldn't need to call two pip commands, but this is an exceptionally minor benefit that is hardly worth mentioning (though, hey, I've got to pad my list, right?)
3. If this feature were further embraced (such as via a config option, so it could be a "default" for my environments), then risk of forgetting to pip check would be reduced, and there's be greater "fail fast" coverage.

I'm not sure that the direction that I'm proposing is worth the complexity that pip would need to incur, especially with the existing "non-zero = no changes" return code.

Feel free to close this (due to the proposed solution likely not being worth its costs) or keep it open (to represent slightly increased ergonomics around catching conflicts in environments).

[pfmoore]

Thanks for your reply. I'll leave it open for now, to let the other maintainers comment if they wish.

[uranusjr]

I’d name the option pip install --check to imply pip check will be run after pip install. Technically check is always run after install, that how pip emits the conflict message. But pip install --check implies that a failed check will fail install, which is exactly what we want here.

[pradyunsg]

I'm ambivalent -- "meh" is probably the best way to summarise my position.

I think the actual change of making this fail is straightforward:

• add a raise InstallationError("AAAA! CONFLICT! AAAA!") in the right place, and we're done.
• --no-warn-conflicts which will need to be mutually exclusive to this.

One good thing to do though, would be to abort prior to making the installation + doing the wheel builds; which can save a bunch of work.