@efiring @mdboom Can one of you take a look at this soon? I would like to get this merged so travis is useful again.

This snippet illustrates the problem:

from matplotlib import rc_context
from matplotlib.font_manager import findfont, FontProperties, _rebuild
import os

font = findfont(
        FontProperties(family=["sans-serif"]))

with rc_context(rc={
        'font.sans-serif':
        ['cmmi10', 'Bitstream Vera Sans']}):

    font2 = findfont(
        FontProperties(family=["sans-serif"]))

with rc_context(rc={
        'font.sans-serif':
        ['cmmi10', 'Bitstream Vera Sans']}):
    _rebuild()
    font3 = findfont(
        FontProperties(family=["sans-serif"]))

font4 = findfont(
        FontProperties(family=["sans-serif"]))
_rebuild()
font5 = findfont(
        FontProperties(family=["sans-serif"]))

print os.path.basename(font), "should be vera"
print os.path.basename(font2), "should be cmmi"
print os.path.basename(font3), "should be cmmi"
print os.path.basename(font4), "should be vera"
print os.path.basename(font5), "should be vera"

There probably should be a check on RcParams.update to re-build the font-cache if any font-related values are changed, but I don't know that section of the code well enough to see how to do it quickly (I am also worried that doing so will induce circular imports). Long term this should be fixed, short term this change to the test makes it pass (and exercises that the fontmanager works properly) and we should add a warning to the docs that changing font rcparams requires rebuilding the fontmanager.

Thanks for all the investigation on this -- ideally, changing font params should not require rebuilding of the cache -- the cache should be purely informational. I'll have a look to see if there's a way around that, and this additional information is really helpful in honing in on what might be going wrong.

@tacaswell: I've restarted the Travis build here (and will probably do it a few more times) just to make sure your test fix does the trick... If it does, that really diagnoses the problem quite well and paves the way forward for a more complete solution. Honestly, I've spent a long time on this, but this is the closest to a diagnosis we've come, so thanks a lot.

I've merged this, as you say, to get tests passing. What is needed as a real fix, though, does not have to be triggering a rebuild of the font manager upon rcParams update, but merely clearing of the lookup caches inside the font manager.

See #3077 for such a fix. If #3077 proves to be effective, we should roll this back so that the bug is still exercised by the tests.