Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating the message when the user hits a conflict w/ installed packages #8546

Closed
pradyunsg opened this issue Jul 5, 2020 · 21 comments · Fixed by #8594
Closed

Updating the message when the user hits a conflict w/ installed packages #8546

pradyunsg opened this issue Jul 5, 2020 · 21 comments · Fixed by #8594
Assignees
Labels
!release blocker Hold a release until this is resolved UX User experience related
Milestone

Comments

@pradyunsg
Copy link
Member

pradyunsg commented Jul 5, 2020

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:

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.0

Note the line starting with "ERROR:".

@pradyunsg pradyunsg added !release blocker Hold a release until this is resolved UX User experience related C: new resolver labels Jul 5, 2020
@pradyunsg pradyunsg added this to the 20.2 milestone Jul 5, 2020
@pradyunsg pradyunsg added this to Needs triage in Resolver Rollout via automation Jul 5, 2020
@pradyunsg pradyunsg moved this from Needs triage to To do before beta in Resolver Rollout Jul 5, 2020
@pradyunsg pradyunsg removed the !release blocker Hold a release until this is resolved label Jul 5, 2020
@pradyunsg pradyunsg removed this from the 20.2 milestone Jul 5, 2020
@pradyunsg pradyunsg self-assigned this Jul 6, 2020
@pradyunsg
Copy link
Member Author

pradyunsg commented Jul 6, 2020

/cc @ei8fdb @nlhkabu for their inputs on the messages to present to the users in both these cases.

@nlhkabu
Copy link
Member

nlhkabu commented Jul 7, 2020

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-resolver to 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

@nlhkabu
Copy link
Member

nlhkabu commented Jul 8, 2020

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 :)

@ei8fdb
Copy link
Contributor

ei8fdb commented Jul 8, 2020

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-resolver to 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.

@nlhkabu
Copy link
Member

nlhkabu commented Jul 8, 2020

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 :)

@nlhkabu
Copy link
Member

nlhkabu commented Jul 8, 2020

@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 :)

@brainwane
Copy link
Member

brainwane commented Jul 15, 2020

it would be useful to be able to tell users when the new resolver will become default

I think we should say "October 2020".

@nlhkabu
Copy link
Member

nlhkabu commented Jul 15, 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

@pypa pypa locked as resolved and limited conversation to collaborators Jul 15, 2020
@pradyunsg
Copy link
Member Author

pradyunsg commented Jul 15, 2020

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? ;)

@uranusjr
Copy link
Member

uranusjr commented Jul 15, 2020

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.

@pfmoore
Copy link
Member

pfmoore commented Jul 15, 2020

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 🙂

@nlhkabu
Copy link
Member

nlhkabu commented Jul 15, 2020

Thanks for your feedback @pfmoore @uranusjr - message updated.

@pradyunsg
Copy link
Member Author

pradyunsg commented Jul 15, 2020

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.

@pradyunsg pradyunsg added this to the 20.2 milestone Jul 16, 2020
@pradyunsg pradyunsg added the !release blocker Hold a release until this is resolved label Jul 16, 2020
@pradyunsg
Copy link
Member Author

pradyunsg commented Jul 16, 2020

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.

@ei8fdb
Copy link
Contributor

ei8fdb commented Jul 22, 2020

@pradyunsg @nlhkabu

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.0

The 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?

@pfmoore
Copy link
Member

pfmoore commented Jul 22, 2020

@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.

@ei8fdb
Copy link
Contributor

ei8fdb commented Jul 22, 2020

@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?

@pfmoore
Copy link
Member

pfmoore commented Jul 22, 2020

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".

@brainwane
Copy link
Member

brainwane commented Jul 23, 2020

would be shown for only 48 hours, after which it would be hidden. This approach was suggested by @dstufft and @pfmoore in another ticket.

#8586 is also relevant here.

@pradyunsg
Copy link
Member Author

pradyunsg commented Jul 23, 2020

@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)).

@brainwane
Copy link
Member

brainwane commented Jul 27, 2020

@ei8fdb if I understand correctly, we need a response from you here as soon as possible, because this is blocking the 20.2 release.

@nlhkabu nlhkabu removed their assignment Jul 28, 2020
Resolver Rollout automation moved this from To do before beta to Closed Jul 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
!release blocker Hold a release until this is resolved UX User experience related
Projects
No open projects
Resolver Rollout
  
Closed
Development

Successfully merging a pull request may close this issue.

6 participants