Thank you for working on this @Croadden

The test failures are real and caused by these changes because win32FontDirectory uses some windows-only modules. This logic will have to be behind some platfrom gating. I suspect that 👍🏻

ifsys.platfrom=='win32'and ...:

would be enough becauseand will short circuit and not evaluate the second expression if the first isFalse.

Could you please also give the PR title and the commit messages more descriptive text (like "FIX: skip sub directories when finding fonts on windows") so that someone who is coming across this issue / commit in the future will have are very quick suggestion as to the motivation for the change. What files you changed and the actually changes is in the diff so the commit message is a chance for you to tell the future readerswhy you made this change!

Damn, was pretty sure I saw OS check :(
My bad, will fix. Sorry, I'm kinda new at github and whole this open source stuff

@tacaswell, I was pretty sure I used propper commit naming... Also I'm not able to rename commits without force pushing and rebasing, so maybe lets leave it as is for now? Lesson learnt.

Oh, found it! I'm using github desktop and I edditedcommit description, but notcommit summary. So that's why commit messages isUpdate font_manager.py instead ofadd win32 fonts directory check andFIX: skip sub directories when finding fonts on windows

Oh, found it!

I'm glad you sorted it out! The summary (e.g. the first line) is very helpful when skimming the history.

Unfortunately there is no way to update the commit message (which even though the UI shows it as two things is really just 1 block of text) is one of the values that git hashes to compute the SHA of the commit (which while annoying here, it means that someone can not change history without someone noticing!). As changing the message changes the SHA (and hence history) you have to force-push to publish the new commits. Again, git is trying to be helpful here and make sure that you do not accidentally delete history (think of the case where two people are working on the same branch. If both fetch the upstream branch, do some work and commit. The first person to push it works, the second person to push it fails (because if it did work it would effectively delete the commit from the first person). From git's point of view it can not tell "I change a commit and want to update it" from "two people are trying to push completely different work" sopush says no, butgit push --force-with-lease says "trust me git, I know what I am doing!".

Sorry for the wall of text, hopefully it is more helpful than harmful.

Your wall of the text help me so much, thanks! :)

But I made a lot of mistakes here. Sorry for being bad, my git experience is so low (was using SVN only for more than 5 years)
I fixes the issue with naming using rebase and everything seems fine in git and git gui (I have only 2 commits with proper naming here), but history seems broken here, at github. So what should I do? Maybe create another branch, delete this one and make another pull request?

@Croadden may I fix it and force-push to your branch?

@tacaswell Sure, no problem, it's just simple reformat

@tacaswell as you go, you can include my suggestion above.

Done!

Steps I took:

• use the GH ui to commit@timhoffm 's suggestion
• checked out the branch locally with the namefix_win32_fonts
• git rebase -i back to where this forked from master (I used magit in emacs to set this up)
• squashed everything down into one commit via the UI (could have maybe dropped duplicate commits, but squashing and fixing conflicts seemed like it would be faster)
• fixed up a conflict as the rebase went
• force pushed to your main branch:git push -v --force-with-lease Croadden fix_win32_fonts:refs/heads/main (again actually done through magit)
• wrote this note

Thanks!

Thanks @Croadden! Congratulations on your first PR to Matplotlib 🎉 We hope to hear from you again.

Will do my best :)
Thanks!