Current coverage is 62.17% (diff: 100%)

Merging #7907 into master will decrease coverage by <.01%

@@             master      #7907   diff @@
==========================================
  Files           174        174          
  Lines         56121      56121          
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
- Hits          34896      34894     -2   
- Misses        21225      21227     +2   
  Partials          0          0          

Powered by Codecov. Last update 1be56c8...f111088

Does this mean our font finding is broken in 2.0?

• Sorry for breaking this.
• The test needs to be skipped on Windows.
• We need to see why this did not break the Travis tests and wasn't more widely reported as this should a priori be a huge issue for any linux users.

It's not widely reported because of the setting USE_FONTCONFIG = False in font_manager.py so we don't really use fontconfig. In #7906 someone is using the functions directly.

What are (or would be) the reasons to use it or not to use it?

• If fontconfig is not used by default, I don't understand why people were seeing the fc-list "slow" warning before.
• In general, I'd say experimental code from 10 years ago should either be turned on by default (on Arch Linux, the ttf-dejavu package (providing the new default font, I guess?) depends on fontconfig, so at least here it's effectively not an extra dependency) or removed...

I think that USE_FONTCONFIG setting works the opposite way. Setting it to True will use fc-match to find fonts, whereas setting it False (or on Windows) will use FontManager and trigger the fc-list call modified herein. The default is False.

Has the Travis cache been working too well, and we've just been reloading the correct font list all this time?

If we need to trigger a cache rebuild, we should probably bump FontManager.__version__ at this point as well.

OK, I think I have an idea; in findSystemFonts, we also do a recursive search through some default directories. The line right after that discards any non-existent files (meaning the fc-list result is discarded.)

So we're essentially looking for fonts twice, once via fc-list and once in some default directory. Apparently, no-one puts fonts elsewhere.

I agree with @QuLogic 's analysis of what is gonig on and why this still appears to work.

This should still be backported to 2.0.x (even if it is not as critical as it first appears).

The backport is annoying because skipif is not defined on 2.0.x. I'll deal with this tomorrow.

@QuLogic Regardless of why this was not an issue, one of the builds of the matrix could start with a removal of ~/.config/matplotlib/fontList.* so that font-finding is tested at least once.

Indeed, my bad.

Backported to v2.0.x as fe1641b.