Skip to content

[4.2rc1] test_bbox_size failure with Python 3.8/3.9 #11007

Closed
#11022
Closed
[4.2rc1] test_bbox_size failure with Python 3.8/3.9#11007
#11022
Labels
testingvisualization.wcsaxes
Milestone
v4.2

Description

@olebole
olebole
opened on Nov 9, 2020

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

  1. olebole
    changed the title [-][4.2rc1] test_bbox_size failure with Python 3.8[/-] [+][4.2rc1] test_bbox_size failure with Python 3.8/3.9[/+] on Nov 9, 2020

  2. pllim commented on Nov 9, 2020

    @pllim
    pllim
    on Nov 9, 2020
    Member

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

    cc @astrofrog and @Cadair

  3. pllim
    added
    visualization.wcsaxes
    testing
    on Nov 9, 2020
  4. pllim
    added this to the v4.2 milestone on Nov 9, 2020

  5. dhomeier commented on Nov 9, 2020

    @dhomeier
    dhomeier
    on Nov 9, 2020
    Contributor

    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.

  6. olebole commented on Nov 9, 2020

    @olebole
    olebole
    on Nov 9, 2020
    MemberAuthor

    The Debian patches for matplotlib are here. I don't see anything that would be relevant for get_tightbbox, but please crosscheck.

  7. dhomeier commented on Nov 9, 2020

    @dhomeier
    dhomeier
    on Nov 9, 2020
    Contributor

    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?

  8. olebole commented on Nov 9, 2020

    @olebole
    olebole
    on Nov 9, 2020
    MemberAuthor

    Matplotlib is built against libfreetype-dev 2.10.2, which is also the current runtime version.

  9. olebole commented on Nov 9, 2020

    @olebole
    olebole
    on Nov 9, 2020
    MemberAuthor

    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.

  10. dhomeier commented on Nov 9, 2020

    @dhomeier
    dhomeier
    on Nov 9, 2020
    Contributor

    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.

  11. Cadair
    closed this as completedin #11022on Nov 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    testingvisualization.wcsaxes

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions