-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Introduce DiagnosticPipError
and use it "once"
#10538
Conversation
This looks fine for me! I just noticed that an (unrelated?) test failed (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only skimmed the PR but this looks very nice !
As the transition period may be long, is there a need to pay attention that legacy errors and new-style exceptions render coherently ?
b246e8e
to
afd7973
Compare
Nudge for 👀 and green ticks. 😅 |
This looks good to me. The last thing I wanted to do is compare the display of old and new style errors. |
I like this in principle. My biggest reservation is how this will look on the various terminals people use, and how it degrades in cases where people have limited fonts, or terminals with rendering glitches. That's not something we can test for, it really needs people eyeballing the output on different devices. It might be nice to add a little "driver" script to generate some sample output so that people can see what it looks like. For example, the "warning sign" emoji renders too wide in the github UI using my browser (Firefox on Windows 10) making following text look misaligned: Also, that same character renders incorrectly in gvim on Windows: I don't think either of these is particularly bad, especially as only developers will see them, but if I print the "fancy" output on a default Windows cmd prompt (not using a modern terminal like Windows Terminal, just the standard console host) I get this: There's only so much we can do about this, but we may want to be conservative, given that a lot of Python users these days are not necessarily familiar with the command line, and are using Windows. (Hmm, has anyone tested how this looks in things like Jupyter using I feel sad that I'm arguing against this - I like the look, and I'm personally using tools capable of handling the Unicode characters just fine (and I'm knowledgeable enough to know what's happening if they go weird on me). But we're very much into UX/UI stuff here, and I fear that friendly but garbled diagnostics may actually make things worse for a non-trivial part of our user base. Do we have anyone with access to users in the newcomer or non-technical communities who can get some real feedback, rather than just my theorising? |
I'm painfully aware that the fancy output will need to be gated behind "does the user have a reasonably modern terminal" check, and definitely intend to be mindful of those use cases. I might end up porting over https://github.com/zkat/supports-unicode/blob/main/src/lib.rs, to add that check in our terminal output stuff (which might make sense anyway) -- but we'll cross that bridge when we get there. For now though, I've not actually used the "fancy" output in anything that pip actually prints out -- rather, the logging infrastructure is using the plain string styling (no reference block, no unicode characters etc. See the |
I think I'm gonna need to get a Windows VM, or a Windows machine. >.< Update: https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/ -- yay new Microsoft that is actually pro-developer! |
😄 You will be assimilated... If it's relatively easy-to-reproduce stuff, I'm happy to test things. Feel free to ping me. The more specific, the more likely I'll "just do it" - vaguer things like PR reviews or actually doing any coding are unfortunately being delegated at the moment to the mythical "when I have some spare time" period in the far future 🙁 |
Alright, if the only concerns are that the fancy output will need sanity checks… it’s not used in the output yet. I don’t know how to trigger the specific error whose messaging I’ve tweaked here. 😅 I thought it’d be an easy one, but it’s being surprisingly annoying to figure out how to trigger this. I’ll pick up an easier to test example for the next one, and I’m sure we’ll have time to iterate and improve the messages/format as we add more of these. |
Alrighty. Updated this PR to add a few easy-to-test errors. Before: ❯ pip install ./tests/data/src/pep518_invalid_requires
Processing ./tests/data/src/pep518_invalid_requires
ERROR: file:///Users/pradyunsg/Developer/pip/tests/data/src/pep518_invalid_requires has a pyproject.toml file that does not comply with PEP 518: 'build-system.requires' is not a list of strings.
❯ After: ❯ pip install ./tests/data/src/pep518_invalid_requires
Processing ./tests/data/src/pep518_invalid_requires
ERROR: Can not process file:///Users/pradyunsg/Developer/pip/tests/data/src/pep518_invalid_requires
This package has an invalid `build-system.requires` key in pyproject.toml.
It is not a list of strings.
Note: This is an issue with the package noted above, not pip.
Hint: See PEP 518 for the detailed specification.
❯ Before: ❯ pip install ./tests/data/src/pep518_invalid_build_system
Processing ./tests/data/src/pep518_invalid_build_system
ERROR: file:///Users/pradyunsg/Developer/pip/tests/data/src/pep518_invalid_build_system has a pyproject.toml file that does not comply with PEP 518: it has a 'build-system' table but not 'build-system.requires' which is mandatory in the table
❯ After: ❯ pip install ./tests/data/src/pep518_invalid_build_system
Processing ./tests/data/src/pep518_invalid_build_system
ERROR: Can not process file:///Users/pradyunsg/Developer/pip/tests/data/src/pep518_invalid_build_system
This package has an invalid pyproject.toml file.
The [build-system] table is missing the mandatory `requires` key.
Note: This is an issue with the package noted above, not pip.
Hint: See PEP 518 for the detailed specification.
❯ |
89baaad
to
3dc8f45
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for working on this!
I have been using Python on Windows for some 6 years and i twerked my setup to be as good as it get. The best setup i found was ConEmu with git bash as default console. I can say that as a developer, Windows is a huge pain. If ever we are to rely on emojis appearing on the command prompt of Windows, i can say that we might be effectively waiting till doomsday for that to happen. And as such we are missing big on user experience. Point is i feel that we should disregard the command prompt as a criteria. 2nd is that windows has WSL now which is becoming the standard as for example docker for windows does not run without it. Wsl should give you a near 98% of what Linux terminals are. You kind of no longer need windows-only tools, just use WSL. Icons and more are great. here is something to look at @pradyunsg I think this is something worth exploring as i don't see any windows version not having WSL in the future. If a win user is reading this, your best bet as a developer is to switch to Linux, with something like Linux Mint to dual boot. You get so much to grow as a developer. |
I don’t think there’s any reason to berate Windows as a development platform or to treat it as a second class OS. I’ve noticed that even certain Linux distros and terminal on MacOS also struggle with emojis. As for Windows, the Windows Terminal ships as default in Windows 11, if I understand correctly and it is also a part of the build for the developer-focused Evaluation VM images I linked to above. Windows has a significantly nicer experience than other platforms, if you have the right tools, and I don’t think that pip will go down the route of treating users sub-optimally; just because of the console host they’re running. I’m leaning toward dropping the emojis FWIW — I don’t like that they don’t have a consistent presentation style across platforms and font settings especially on Linux. I’d prefer to do that stuff in a follow up PR, because this one’s already getting a bit too long and I don’t wanna be changing too many things in one go. :) |
For development, Python specifically i think that's not true. It's a real pain. Take CPython dev for example. Yes windows is great to develop on ... to improve windows support.
The thing is that many dev happen on unix-based systems and as such Windows is bound not to be in phase with many projects without directed efforts. Even then, the command prompt is not the nicest terminal around, by far. The best thing is to intelligently detect emoji support in the terminal the output is redirecting to. Then output with or without emojis accordingly. Maybe that's difficult to do. |
This introduces an exception and presentation model, for providing better errors messages. The motivating idea is that the better error messages contain clear wording and provide additional context to users to better understand what is happening. The `DiagnosticPipError` class introduces a structured framework in our exception model, for code authors to write their error messages. The usage explicitly requires passing "context" and a "hint" (which accept None values). This should nudge code authors to explicitly think about what additional information can/should be presented to the user, and to provide relevant hints to them whenever possible. It also makes it straightforward to identify cases where we don't do this, which may serve as clear areas for improvement in the future. The initial implementation is intentionally basic and doesn't do much; however we should be able to introduce better usage of terminal colors and other features (eg: hyperlinks!) to further improve the presentation of these errors. It does improve the presentation style by a bit, even though there are significant presentation-related improvements to be made. Additionally, having a structured framework means that these would be improvements in presentation of *all* the errors that are within this framework -- increasing the benefits of investing in the presentation of these errors.
Co-authored-by: Ed Morley <501702+edmorley@users.noreply.github.com>
8ed3800
to
fca233c
Compare
This demonstrates how the new diagnostic errors are to implement, and how they get presented to users.
Alrighty. This is pretty much ready to review/merge IMO.
In other news, I prototyped a bit more with the presentation for this, using rich, and tweeted about that here: https://twitter.com/pradyunsg/status/1450573310308364294 I'd really like to get this merged soon, so that I can start iterating more on this; to start figuring out the details of the fancier presentation as well as get more of the actual error message improvements filed as PRs. :) |
fca233c
to
a00e7bc
Compare
Reading the discussions again today, it seems to me that there's reasonable concensus that we want to do something like this. I'm gonna go ahead and merge this, to serve as the first iteration for these error message improvements -- I'll keep iterating on this as we go, and I'm happy to incorporate more feedback as it comes in. Please do feel free to suggest improvements / raise concerns in #10421. :) |
Okay, I admit, I nerd-sniped myself into this one. There's decently elaborate commit messages on this one. If you're just here to see how the diagnostic errors might look, see the two
test_complete
methods, on the test class.This makes a whole lot of progress toward #10421.
I'd like to get some 👀 on this for gathering feedback on the "overall shape" this is taking.