Updating the message when the user hits a conflict w/ installed packages #8546
Comments
pradyunsg
added
!release blocker
Warn users the new behaviour might behave differently
Nudge users "hey, do you want the resolver to always be strict!? tell us!"4 variations depending on whether the user is upgrading or installing, and depending on how many packages they are requesting:
|
|
ping @pradyunsg - can you please confirm that these are accurate? Thanks both :) |
Warn users the new behaviour might behave differentlyQuestions:
If the message is for maintainersI assume:
Here is my iteration on @nlhkabu's message above:
If the message is for any user (maintainer or user installing packages)If the message is for any user, then we need to frame it for everyone. Here is my iteration on @nlhkabu's message above:
Nudge users "hey, do you want the resolver to always be strict!? tell us!"
For this line, I suggest we create a template for users to help them understand what we expect them to tell us. |
|
Hi @brainwane - as discussed in a team meeting, it would be useful to be able to tell users when the new resolver will become default. My new iteration on Bernard's error message:
Summary, we need |
|
@pradyunsg instead of nudging users towards the issue tracker, @ei8fdb and I discussed that it might be better to direct them to a survey - I've put one together here: https://forms.gle/JpMP2kBuMDqzbC768 As a bonus we can also publicise this survey on Twitter, mailing groups, etc. to get feedback from a wider group of pip users. Let me know if you would like any changes to the survey :) |
I think we should say "October 2020". |
|
Final error messages: Warn users the new behaviour might behave differently
Nudge users "hey, do you want the resolver to always be strict!? tell us!"
|
Is the expectation that we'd print a different error message based on some context? (that seems unnecessary to me -- please elaborate on how/why if that's the expectation) Or... can I just pick one of these? ;) |
|
I’d say it’s good enough to have one message that says “install/upgrade” and always use the plural form. I had to read the messages three times to find out the differences. Odds are the users won’t notice at all if they see different variants of these. |
|
Grammar nit - "it's dependencies" should be "its dependencies". I agree with @uranusjr about the 4 variations, though. Apart from anything else, we could get into some very complicated discussions if we try to distinguish "install" and "upgrade" (and there's also "downgrade"!!!) But I'd like @nlhkabu to confirm that's OK. There's not much point getting a UX expert's opinion, and then ignoring it 🙂 |
|
Q: Do we want the error message to stay in the current location or should we move it to be printed after installation? If "move", any comments on which of the two alternate locations would be better? I think changing the location of the message would be a worthwhile change -- if pip's "install step" prints a lot of messages (eg: lots of packages were installed), we'd have a significant distance between the end of the output and the message that has been printed, resulting in users potentially missing it. @ei8fdb have discussed this briefly in the past and (IIRC) he'd agreed that this would be a good change. |
I've gone ahead and filed #8590 that changes this to alternative location 1. |
|
Pradyun asked for input on this as it was blocking him. Looking back to Nicole's original message suggestion, we should implement that message, but include some spacing as follows: Installing collected packages: pycodestyle, flake8-import-order, pyflakes, mccabe, flake8
<BLANK LINE>
Warning: After October 2020 you may experience errors when installing or updating packages. This is because pip will change
the way that it resolves dependency conflicts.
We recommend you use --use-feature=2020-resolver to test your packages with the new resolver before it becomes the default.
<BLANK LINE>
Warning: Pip will install or upgrade your package(s) and its dependencies without taking into account other packages you already have installed. This may cause an uncaught dependency conflict.
<BLANK LINE>
If you would like pip to take your other packages into account, please tell us here: https://forms.gle/cWKMoDs8sUVE29hz9
<BLANK LINE>
flake8 3.5.0 requires mccabe<0.7.0,>=0.6.0, but you'll have mccabe 0.5.3 which is incompatible.
flake8 3.5.0 requires pycodestyle<2.4.0,>=2.0.0, but you'll have pycodestyle 2.6.0 which is incompatible.
Successfully installed flake8-3.5.0 flake8-import-order-0.17.1 mccabe-0.5.3 pycodestyle-2.6.0 pyflakes-1.6.0The spacing is to improve the formatting of this output text - otherwise the important message explaining 1) pip behaviour is changing, 2) recommendation on ways to minimise impact of the changes, 3) request for user input on what future pip behaviour should be, are lost in this blob of text. Pradyun is concerned the message (from Warning: After October 2020....to....please tell us here: LINK) is too long and will annoy users once it's been shown once, so I'm suggesting this part of the message: would be shown for only 48 hours, after which it would be hidden. This approach was suggested by @dstufft and @pfmoore in another ticket. @dstufft @pfmoore is there a recommended approach/reusable code to implement hiding the message portion? |
Not that I know of. Someone would just have to code it directly. I'm not sure what "for only 48 hours" means, but if it's intended to be based on when the user first saw the message, that would mean keeping persistent information on the user's PC, and I'm not sure how you'd expect to do that. |
|
@pfmoore I'm talking specifically about what was mentioned in the deprecate pip search issue: "We could also bake some sort of time gating right into the message, like in the Python code check if the date is before some cut off date before showing the message." Can someone describe what the user would see in terms of the functionality suggested here? |
|
OK, cool, so it's just "if the date is after such-and-such then don't show that bit of the message". That's easy enough to not need a "recommended approach/reusable code". |
|
@ei8fdb So, could you clarify which one of these you want:
The former is #8586, and the latter is... more complex as Paul noted already (in #8546 (comment)). |
|
@ei8fdb if I understand correctly, we need a response from you here as soon as possible, because this is blocking the 20.2 release. |
Environment
Description
We've decided to update the error message presented to a user, when the final result set of packages will contain dependency conflicts.
Context: #8513, #7744 and a recent team meeting regarding the new resolver rollout.
Expected behavior
The behavior has to be changed in two ways, each related to a different part of the resolver rollout plan:
How to Reproduce / Output
To get the current message, run:
Note the line starting with "ERROR:".
The text was updated successfully, but these errors were encountered: