Repository navigation
[4.2rc1] test_bbox_size failure with Python 3.8/3.9 #11007
Description
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
Activity
[-][4.2rc1] test_bbox_size failure with Python 3.8[/-][+][4.2rc1] test_bbox_size failure with Python 3.8/3.9[/+]pllim commentedon Nov 9, 2020
Ah... I think we relaxed the rules to skip this test, @dhomeier ?
cc @astrofrog and @Cadair
dhomeier commentedon Nov 9, 2020
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
x1andy1values for different Matplotlib versions, but differentx0values (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_tightbboxalso returns inconsistent values across different platforms, we might have to skip or xfail that test after all.olebole commentedon Nov 9, 2020
The Debian patches for matplotlib are here. I don't see anything that would be relevant for
get_tightbbox, but please crosscheck.dhomeier commentedon Nov 9, 2020
Don't find anything at a first glance, but I note there are some relaxations for the internal tests. Is the package built against the reference freetype-2.6.1 or a different version?
olebole commentedon Nov 9, 2020
Matplotlib is built against libfreetype-dev 2.10.2, which is also the current runtime version.
olebole commentedon Nov 9, 2020
If it depends on tiny things here: it is built against a version of libfreetype with all (from Debian's POV) non-free stuff removed. If this applies to fonts or fontcalcs, there may be subtle differences.
dhomeier commentedon Nov 9, 2020
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.12could get around this.