Updating the message when the user hits a conflict w/ installed packages
pradyunsg opened this issue · 21 comments
Environment
- pip version: master today.
- Python version: all
- OS: all
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:
- The legacy resolver would present a message nudging users to realize that the upcoming new resolver might behave differently (see #8513)
- The new resolver would present a message nudging users "hey, do you want the resolver to always be strict!? tell us!" (see #7744 (comment))
How to Reproduce / Output
To get the current message, run:
$ pip install six==1.10.0
$ pip install cherrypy==11.0.0
Collecting cherrypy==11.0.0
Downloading CherryPy-11.0.0-py2.py3-none-any.whl (435 kB)
|████████████████████████████████| 435 kB 5.3 MB/s
Requirement already satisfied: six in /Users/pradyunsg/.virtualenvs/tmp-7af976d02abc202/lib/python3.8/site-packages (from cherrypy==11.0.0) (1.10.0)
Collecting portend>=2.1.1
Downloading portend-2.6-py2.py3-none-any.whl (5.1 kB)
Collecting cheroot>=5.2.0
Downloading cheroot-8.3.0-py2.py3-none-any.whl (86 kB)
|████████████████████████████████| 86 kB 5.9 MB/s
Collecting tempora>=1.8
Downloading tempora-3.0.0-py2.py3-none-any.whl (14 kB)
Collecting more-itertools>=2.6
Using cached more_itertools-8.4.0-py3-none-any.whl (43 kB)
Collecting jaraco.functools
Downloading jaraco.functools-3.0.1-py3-none-any.whl (6.7 kB)
Collecting pytz
Using cached pytz-2020.1-py2.py3-none-any.whl (510 kB)
ERROR: cheroot 8.3.0 has requirement six>=1.11.0, but you'll have six 1.10.0 which is incompatible.
Installing collected packages: more-itertools, jaraco.functools, pytz, tempora, portend, cheroot, cherrypy
Successfully installed cheroot-8.3.0 cherrypy-11.0.0 jaraco.functools-3.0.1 more-itertools-8.4.0 portend-2.6 pytz-2020.1 tempora-3.0.0Note the line starting with "ERROR:".
Warn users the new behaviour might behave differently
Warning: Your project may soon experience errors when pip updates the way that it resolves dependency conflicts.
Use--use-feature=2020-resolverto test your project with the new resolver before it becomes the default.
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:
Warning: Pip will install your package and it's dependencies without taking into account other packages you already have installed. This may cause an uncaught dependency conflict.
If you would like pip to take your other packages into account, please tell us here:issue_tracker_url
Warning: Pip will install your packages and their dependencies without taking into account other packages you already have installed. This may cause an uncaught dependency conflict.
If you would like pip to take your other packages into account, please tell us here:issue_tracker_url
Warning: Pip will upgrade your package and it's dependencies without taking into account other packages you already have installed. This may cause an uncaught dependency conflict.
If you would like pip to take your other packages into account, please tell us here:issue_tracker_url
Warning: Pip will upgrade your packages and their dependencies without taking into account other packages you already have installed. This may cause an uncaught dependency conflict.
If you would like pip to take your other packages into account, please tell us here:issue_tracker_url
ping @pradyunsg - can you please confirm that these are accurate?
ping @ei8fdb - can you please review copy and make suggestions if you feel we can make it better.
Thanks both :)
Warn users the new behaviour might behave differently
Questions:
- Can we put a date (even just month is OK) to give the maintainer a better indication when "soon" is?
If the message is for maintainers
I assume:
- the maintainer is the intended audience of this message
- we want the maintainer to test their project with the new resolver -> I suggest using stronger language; "we recommend you test....", etc
- if the maintainer does test their project and finds issues - we expect them to fix their own issues
Here is my iteration on @nlhkabu's message above:
Warning: After $MONTH users installing your project may experience errors. This is because pip will update the way that it resolves dependency conflicts.
We recommend you use--use-feature=2020-resolverto test your project with the new resolver before it becomes the default.
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:
Warning: After $MONTH you may experience errors when installing/updating packages. This is because pip will update the way that it resolves dependency conflicts.
We recommend you use --use-feature=2020-resolver to test packages with the new resolver before it becomes the default.
Nudge users "hey, do you want the resolver to always be strict!? tell us!"
If you would like pip to take your other packages into account, please tell us here: issue_tracker_url
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:
Warning: After $MONTH 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.
Summary, we need $MONTH :)
@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 :)
it would be useful to be able to tell users when the new resolver will become default
I think we should say "October 2020".
Final error messages:
Warn users the new behaviour might behave differently
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.
Nudge users "hey, do you want the resolver to always be strict!? tell us!"
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.
If you would like pip to take your other packages into account, please tell us here: https://forms.gle/cWKMoDs8sUVE29hz9
4 variations depending on whether the user is upgrading or installing, and depending on how many packages they are requesting:
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?
Collecting pytz
Using cached pytz-2020.1-py2.py3-none-any.whl (510 kB)
Processing ./pkgB
Using legacy setup.py install for pkgB, since package 'wheel' is not installed.
<<< current warning location >>>
Installing collected packages: pytz, pkgB
Running setup.py install for pkgB: started
Running setup.py install for pkgB: finished with status 'done'
<<< alternative location 1 >>>
Successfully installed pytz-2020.1 pkgB-2.0
<<< alternative location 2 >>>
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.
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'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:
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.
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.
If you would like pip to take your other packages into account, please tell us here: https://forms.gle/cWKMoDs8sUVE29hz9
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?
@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:
- if it's been less than 48 hours since the release, and user hits this issue, show MESSAGE
- if it's been less than 48 hours since the user started using this release, and user hits this issue, show MESSAGE
The former is #8586, and the latter is... more complex as Paul noted already (in #8546 (comment)).