Yes, Tcl/Tk is technically optional, but it is usually included. However, I am not entirely convinced that restricted environments like google app engine would really benefit from having tkagg available. These sort of environments are intended to be headless environments, anyway, so having AGG available is sufficient.
My concern is about making it easier for everyone else, even if it will take some time to get there. Who would be best to head up the submission of the patch to Tkinter? On Wed, May 4, 2016 at 5:30 AM, Nathaniel Smith <[email protected]> wrote: > On Wed, May 4, 2016 at 12:40 AM, Olivier Grisel > <[email protected]> wrote: > > 2016-05-03 22:47 GMT+02:00 Matthew Brett <[email protected]>: > >> On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel < > [email protected]> wrote: > >>>> I tested it with: > >>>> > >>>> import matplotlib > >>>> matplotlib.use('PyQt5') > >>> > >>> Typo, this was supposed to read: > >>> > >>> matplotlib.use('Qt5Agg') > >> > >> Meanwhile, I tried removing (patchelf --remove-needed) the > >> requirements of _tkagg.so on the vendored libtk, libtcl, and added > >> back the requirement (patch --add-needed) on general `libtk.so' and > >> 'libtcl.so'. This removed the segfault and allowed me to display > >> `plt.range(10)'. I suppose then, that the tk / tcl ABI that we are > >> using is relatively stable across versions 8.4 (on the docker image) > >> and 8.6 (on Debian sid). > >> > >> Worth experimenting with this - or too much of a hack? > >> > >> Is there a way to add libraries to ignore, in `auditwheel repair` ? > > > > It sounds reasonable to add this feature as a CLI option to me. > > > > Also maybe we could decide to amend PEP 513 to add libtk.so and > > libtcl.so to the system provided white-list as they are direct > > dependencies for Python via tkinter which is part of the standard > > library. > > I believe that they're optional dependencies, i.e. if you build python > on a system that's missing TCL/TK then it just disables those modules? > They might be available-in-fact on every system we care about, I don't > know -- but unfortunately we can't assume that they're > available-in-principle :-/. > > (It looks like Debian at least splits tk off into its own python-tk > package.) > > -n > > -- > Nathaniel J. Smith -- https://vorpus.org > _______________________________________________ > Matplotlib-devel mailing list > [email protected] > https://mail.python.org/mailman/listinfo/matplotlib-devel >
_______________________________________________ Wheel-builders mailing list [email protected] https://mail.python.org/mailman/listinfo/wheel-builders
