-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
MNT: be more careful about disk I/O failures when writing font cache #28541
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
MNT: be more careful about disk I/O failures when writing font cache #28541
Conversation
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.
This makes sense to me. Are all file-related errors now OSError? Just double-checking.
I checked the |
Yes. https://docs.python.org/3/library/exceptions.html#exception-hierarchy |
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.
Take or leave my suggestions. May self merge then.
# 2. import matplotlib which makes sure it exists | ||
# 3. get the cache dir (where we check it is writable) | ||
# 4. make it not writable | ||
# 5. try to write into it via font manager |
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.
# 5. try to write into it via font manager | |
# 5. try to write into it via font manager | |
# 6. Check that we do not raise even though 5. cannot work |
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.
Optional: Check that the log warning is emitted.
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'm going to pass on adding a check for the logging. I don't think we do that systematically currently and because the log emission happens in the sub-process it would take a fair amount of work to check (I think something like the tests for blocking where we print something and them search for the string in stdout).
The locker works by writing a file to disk. This can also fail so make sure we can still import in that case. Closes matplotlib#28538
ba06dc6
to
40f642f
Compare
The windows failures were real, but fortunately we have hit them before and I could copy the fix (Python won't start on windows with an empty env because all of the random number APIs fail). |
Self merging per Tim's comment. |
…lures when writing font cache
…541-on-v3.9.x Backport PR #28541 on branch v3.9.x (MNT: be more careful about disk I/O failures when writing font cache)
The locker works by writing a file to disk. This can also fail so make sure we can still import in that case.
Closes #28538
The only way I could think to test this is very synthetic and requires messing with the file system at in between importing the top level module and font_manager. Still not sure how the OP drove their system to expose this issue. I think it has not come up before because if the directory is not writable we detect that and bail to asking for a temporary directory to work with.
PR checklist