[Matplotlib-devel] [Wheel-builders] Manylinux external library test case - matplotlib, tk

[Nathaniel Smith]

On Apr 25, 2016 10:38 AM, "Matthew Brett" <matthew.brett at gmail.com> wrote:
>
> Hi,
>
> I am building matplotlib manylinux wheels:
>
>
https://github.com/matthew-brett/manylinux-builds/blob/master/build_matplotlibs.sh
>
> The problem is, what to do about the default matplotlib tk optional
dependency?
>
> Normally, matplotlib builds against the installed system tk libs :
> https://github.com/matplotlib/matplotlib/blob/master/setupext.py#L1522
>
> When building a manylinux wheel, we can only build against the tk libs
> / headers on the manylinux docker image, by doing `yum install -y
> tk-devel` before building.
>
> This means that the tk that matplotlib is built against, is different
> from the one that Python uses with `import Tkinter`.  I suppose that
> is what causes the following, when building matplotlib with tk-devel
> installed:
>
> >>> import matplotlib
> >>> matplotlib.get_backend()
> u'TkAgg'
> >>> import matplotlib.pyplot as plt
> >>> plt.plot(range(10))
> [<matplotlib.lines.Line2D object at 0x7f2a8e4b4390>]
> >>> plt.show()
> Segmentation fault
>
> I don't immediately see a good way to deal with this.  Any thoughts?

Maybe obvious, but here's a syllogism:

If:
    matplotlib and python have to agree on which tk libs they are using,
and:
    there are inconsistencies between tk libs on different Linux systems
such that matplotlib must be built against the same tk as it eventually
uses,
then:
    we don't really have any option except to disable tk support in
matplotlib manylinux wheels

So I guess the question to focus on are whether those two premises are
actually true. I guess a backtrace on the segfault would help?

Also: how important is tk support? Do we have a fallback? I know that Qt
packaging is something of a mess right now too...

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160425/bc1c5978/attachment-0001.html>