-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New Resolver Error Reporting (case: ward==0.44.1b0 and py2neo==4.3.0) #8220
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
Comments
Slightly different output with the latest version of the resolver (20.2b1):
What would you like to see in the way of an error that would help diagnose? (I also tried using |
(This install is documented on a gist) Current error messageERROR: Could not find a version that satisfies the requirement pygments<3.0.0,>=2.4.2 (from ward) Verbose explanationNB: this is just for documentation to make sure I understand the situation correctly.
Before you read the error messageThe main decision we need to make first is - what format the error message should take. We are proposing 3 parts to an error message - each of these parts are based on established good user-centred design practice for error messages. Part 1 What is the errorGive explicit indication of what has gone wrong - precise descriptions of exact problems, rather than vague generalities. Part 2 - what has caused the errorProvide an explanation about what has caused pip to display this error. Part 3 - possible ways to solve the errorProvide the user with constructive advice on how to fix the problem. Proposed error messageSo, onto our proposed message for this example. I have included the 3 parts as mentioned above.
(Part 1 What is the error?) (Part 2 - what has caused the error)
(Part 3 - possible ways to solve the error)
For instructions on how to do these steps visit: https://pypa.io/SomeLink" |
Minor point: So to be 100% explicit, you are proposing that the user should see the following:
That seems... rather verbose? It also has a number of practical issues in the "possible solutions" section.
In terms of implementability, the following issues need to be considered:
|
Whats important is the structure of the message - 3 parts:
I understand you and @pradyunsg are reluctant to provide 3., so l'm ok with testing only providing 1 and 2 with users and see the reaction.
If all ResolutionImpossible error are created in the same way, then the error text is as you say boilerplate (better: consistent).
The link to docs was discussed with @pradyunsg @nlhkabu as a way to provide the user with a possible ways to solve the error. The thinking was it is easier and quicker to update a pypa documentation link than roll-out a new version of pip.
This advice came from @pradyunsg, as a suggestion about how to solve this issue. You raise a good point tho' - we've not suggested raising a ticket/bug against the packages the user was trying to install.
I don't understand "use to convert a spec into "human readable" form". Can you explain this more? Will this have an impact on the error message?
As I mention above - if all occurences are triggered the same way then yes keep the message consistent. If not, do we know the other ways it's caused? If not then I agree with, we should make this the message consistent for the moment. (I'm going to open a ticket for ResolutionImpossible error message, as I've done for new resolver flag. I'll reference this.) |
In In general, I'd say:
So basically, we don't have a means of generating that parenthesised explanatory text at the moment, and it's a lot of work (I'd say at least multiple days, quite possibly weeks). Do you consider it important enough to warrant that amount of work? My problem is that as a developer, I tend to de-prioritise UI issues too much, so I automatically assume that "fix the obscure test cases so the test suite passes 100%" is more important than this. Hence why we need guidance here on where to invest effort... |
@pfmoore Is there not a library that handles changing: |
There is not such a library as far as I know. |
Ok, could we do this using a dict? human_readable_operators= {
"<": "less than",
"<=": "less than or equal to",
...
} |
What is is about the project meta data that makes it more complex than this? |
I guess? This will need to handle more complex cases, however, such as |
I think that would be very helpful! |
Note that this is addressing my concern that "it may be hard to do this", but I still believe it should be handled in |
@uranusjr https://www.python.org/dev/peps/pep-0440/#version-specifiers Is this the complete list of possibilities? |
@nlhkabu , @pfmoore @uranusjr @pradyunsg I think it's OK to close this ticket. Thoughts? |
It basically seems like a duplicate of #8377, so yes, let's close this and focus on that one |
Packages ward and py2neo (as reported via the pip research survey)
Resolver will go all the way down to
ward 0.28.0b0
(current version is0.45.0b0
) to resolve dependency conflicts.With pinned versions, here is the output:
The text was updated successfully, but these errors were encountered: