Check if pip broke the dependency graph and warn the user

[pradyunsg]

Until #988 comes along, it seems to me that adding some functionality to pip to let the user know that it broke the dependency graph looks like a good idea to me.

I would like to discuss the merits and demerits of this.

PS: And maybe follow up with implementation if I have spare time after #3786.
PPS: I didn't check for duplicates before opening this.

[xavfernandez]

Cf #3750

[rbtcollins]

This is also a dupe - and even with 988 in place would be needed. I don't have the number handy, but basically conflicts with existing top level distributions with common dependencies.

[pradyunsg]

This won't need #988 since this can be implemented without a dependency resolver.

It's just that pip could use some way to check if some package (a dependency) doesn't fit the requirements/constraints on the version set by another (parent package).

I would consider this an issue that would be resolved by #3750. If it's not merged and closed, this stays open to as a marker that this has to be done.

[rbtcollins]

I am confused; pips existing behaviour (without --ignore-dependencies) is to check everything recursively from the named distributions within the limits of first-seen-specifier [which is what #988 would address] - if you're proposing that we change pip to not do that check, then thats a huge problem. If you're proposing that it needs to do that check - it already does.

The issue I thought this was about is when something not in the recursively reachable set disagrees with a version change caused by some operation.

Perhaps you could provide an example scenario where this bug would apply, so that I can understand what you're suggesting?

[rbtcollins]

See #2687

[pradyunsg]

The scenario in #2687 is indeed the scenario I care about.

It's obviously wrong. pip still does it. pip won't stop doing the wrong thing without a dependency resolver. It is possible to detect this though, independently, and point it out to the user who may then manually resolve it. Any form it takes, like a separate command or a warning at install time, I'm fine with that.

[rbtcollins]

So I think then that this should be considered a dupe of #2687 ?

[pradyunsg]

No. #2687 is to stop breaking the environment. I wish to see a way in pip to warn the user that pip has broken the environment.

[rbtcollins]

That doesn't make sense to me.

[pradyunsg]

That doesn't make sense to me.

I want to let the user check and detect in a scenario like that in OP of #2687 that the dependency of some package is broken, using pip.

[rbtcollins]

But why? Surely its better to not be broken in the first place?

[pradyunsg]

Well... It has been concluded in prior discussions (#59, at pypa-dev) that the behaviour in #2687 is not fixable until #988 lands, which may will take a fair bit of time, and this behaviour is the safer-middle-ground in the mean time.

[pradyunsg]

How about running check after every run of install? That way, pip can print for the user what all it's changed.

Off-topic: When's the next pip release?

[pradyunsg]

With pip check in place, I'm not sure what I think about this myself.

[dstufft]

I'm going to close this, I think that #988 is a better solution to this and we have pip check now for people who want to do this manually.

[waprin]

@dstufft it seems to me that pip install -r requirements.txt should run pip check automatically and print the warning.. Seems like #988 is actually trying to resolve the underlying issue whereas just running pip check automatically for all those who don't realize it exists would be an improvement. Thoughts?

[mhsmith]

#988 is a better solution, but it doesn't look as if it's currently possible. Duplicates of #988 are being reported about once a month, and for every affected user who makes a report there are probably 50 who don't.

For how many more years will pip keep silently producing broken installations? How many more thousands of hours of people's time will be wasted? Just put in the automatic check until you can solve it properly.

[dstufft]

There is a GSoC student who is working on #988 this year.

[mhsmith]

I'm glad to hear that, but that doesn't mean it'll actually get fixed.

[mhsmith]

For future reference: the check-after-install feature was done in #5000 and was released in pip 10.0.0.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.