Improving new resolver output when backtracking choices #8346
Comments
pradyunsg
added
state: needs discussion
|
Some thoughts:
|
I wonder what you mean by this, is it
The progress bar, IMHO, is pretty much similar to the transparent washing machine lid, while it might be useful to track the progress, for many it's even more important because it makes the waiting time more enjoyable.
I'd like to have this too, and this was mentioned in #7815 (comment) as needing refactoring I think. |
This would definitely not be what we do. :) |
I love this comment :-)
This is the option I had in mind. |
|
@pfmoore, if we do that and not using curses or the alike, can the user tell what's been downloaded and what's not, since we'll be limited to one single line I think. Additionally, I believe that it is not possible to fit both the filename and the progress bar within an average console line. Although I'm not entirely sure if it is a good idea to print entire wheel filenames, which are especially long and contain more than enough information (e.g. do I as an user need to care if it's manylinux1 or manylinux2014?). @pradyunsg, is it correct that the expected behavior is at most (in case the more compact output discussed above turns out to be not so doable) something like I also wonder if it is intuitive (to new users) that resolution is happening behind the scene and that the candidates are being rejected that the next one is being downloaded, since the mocked up output above looks kind of strange. |
Agreed, that's why I sort of wonder whether any of this output is worthwhile. But I'm mostly just speculating on what others might like, to be honest. It matters very little to me personally. |
|
I suggest we "look outward" at Rust/npm/brew/poetry etc, to figure out what they show during dependency resolution.
I have no idea what a good answer is. If everyone left it to me, I'd just orient the entire output around the resolver's state, and completely redo pip's output while I'm at it. :) This is semi-inspired by poetry's |
|
What does Poetry’s output look like on backtracking? That’s the thing generating output for us right now, and the above example does not have that. |
|
|
I wouldn’t say that’s meaningfully different than pip’s current behaviour 🙁 |
|
To be clear, poetry's default output is... to not show anything except a timer. :) |
|
Coming from #8467 (comment), if the dependency information is retrieved differently, do we still want to print e.g. Collecting spam 1.0 (I suggest going for the concrete version)? As an user, what I really want here is to have another logging level, where it is not as cluttered as |
|
@pradyunsg @uranusjr @pfmoore - have you made a decision on this? Do you need UX to make a recommendation/specification here? |
|
I think our decision here (through inaction, time constraints, etc) is to leave the status-quo behavior for now. Recommendations and inputs would certainly be welcome. This is closely related to #8453 (arguably, a single case whereas #8453 is the general "umbrella" that covers this), so I imagine we'd likely tackle this as part of working on that. |
nlhkabu
added
the
UX: functionality research epic
pradyunsg
changed the title
|
#8861 contains the dumbest implementation idea I had for reducing the "Collecting ..." lines we print: Becomes: I think that's an improvement, but we might want to do a bunch more here. :) |
|
As I mentioned in #8683 (comment) : The team discussed this problem in last week's meeting and work is now in progress so that pip will inform the user when the resolver is doing a lot of backtracking. We'll probably be giving the user a short in-terminal error message and pointing to longer documentation, as we did with this conflict resolution documentation. |
|
I think I'm happy with where we are with pip 20.3 beta1. Let's close this. |
Environment
Description
pip's new resolver's output is repeating
Collecting XYZfor the same requirement multiple times.Expected behavior
pip's output should not have
Collecting XYZmultiple times.How to Reproduce
pip install --unstable-feature=resolver 'pyrax==1.9.8'Output
The text was updated successfully, but these errors were encountered: