[4.2rc1] test_bbox_size failure with Python 3.8/3.9

Description

When I run the test suite during the build of the Debian package, test_bbox_size fails on Python 3.8 and 3.9.

Expected behavior

The tests should succeed on all supported Python versions.

Actual behavior

I get the following failure:

________________________________ test_bbox_size ________________________________

    def test_bbox_size():
        # Test for the size of a WCSAxes bbox
        x0 = 11.38888888888889
        y0 = 3.5
        # Upper bounding box limits (only have Matplotlib >= 3.0 now)
        x1 = 576.0
        y1 = 432.0
    
        fig = plt.figure()
        ax = WCSAxes(fig, [0.1, 0.1, 0.8, 0.8])
        fig.add_axes(ax)
        fig.canvas.draw()
        renderer = fig.canvas.renderer
        ax_bbox = ax.get_tightbbox(renderer)
>       assert np.allclose(ax_bbox.x0, x0)
E       assert False
E        +  where False = <function allclose at 0x7fb26d2d40d0>(11.26388888888889, 11.38888888888889)
E        +    where <function allclose at 0x7fb26d2d40d0> = np.allclose
E        +    and   11.26388888888889 = Bbox([[11.26388888888889, 3.5], [576.0, 432.0]]).x0

astropy/visualization/wcsaxes/tests/test_misc.py:521: AssertionError
= 1 failed, 15010 passed, 294 skipped, 60 xfailed, 12 xpassed in 717.27 seconds =

Steps to Reproduce

Build (and test) the Debian experimental package (soon in salsa).

System Details

• Python 3.8.6, 3.9.0
• Numpy 1.19.4
• Astropy 4.2rc1
• Scipy 1.5.3
• Matplotlib 3.3.2

[dhomeier]

Ah… I think we relaxed the rules to skip this test, @dhomeier ?

No, originally this was addressed with skipif('not MATPLOTLIB_EQ_33'), but this is with 3.3.2. Per #10952 and #11010 the solution was to test against the correct x1 and y1 values for different Matplotlib versions, but different x0 values (11.2649 vs. 11.3889 here) have actually not popped up so far. For 4.2rc1 on OS X with 3.8 and 3.9, this test passes with Matplotlib 3.0.3 and 3.3.2.

@olebole do you know if the Debian mpl package is applying any additional patches? Otherwise, if get_tightbbox also returns inconsistent values across different platforms, we might have to skip or xfail that test after all.

[dhomeier]

Yes; by default matplotlib requires to test only a build against freetype 2.6.1 to allow exact comparisons against the reference images. I don’t know what the wheels or whatever the CI uses are typically built against, but that might affect the bounding box calculation as well. No idea if there is any straightforward way to probe mpl’s freetype version, but checking with atol=0.12 could get around this.