From olivier.grisel at ensta.org Mon May 2 16:21:33 2016 From: olivier.grisel at ensta.org (Olivier Grisel) Date: Mon, 2 May 2016 22:21:33 +0200 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: Note that PyQt5 developers have released binary wheels for all the supported platforms (windows, OSX and Linux via manylinux1): pip install --upgrade PyQt5 https://pypi.io/project/PyQt5 (the legacy pypi index is broken at the moment). I tested it with: import matplotlib matplotlib.use('PyQt5') and it seems to work as expected. That does not solve the tkinter issue but at least provides an alternative (if you accept the terms of the GPL v3 license). -- Olivier From olivier.grisel at ensta.org Tue May 3 05:35:51 2016 From: olivier.grisel at ensta.org (Olivier Grisel) Date: Tue, 3 May 2016 11:35:51 +0200 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: > I tested it with: > > import matplotlib > matplotlib.use('PyQt5') Typo, this was supposed to read: matplotlib.use('Qt5Agg') -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel From matthew.brett at gmail.com Tue May 3 16:47:20 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 3 May 2016 16:47:20 -0400 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel 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` ? Cheers, Matthew From olivier.grisel at ensta.org Wed May 4 03:40:17 2016 From: olivier.grisel at ensta.org (Olivier Grisel) Date: Wed, 4 May 2016 09:40:17 +0200 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: 2016-05-03 22:47 GMT+02:00 Matthew Brett : > On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel 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. -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel From njs at pobox.com Wed May 4 05:30:09 2016 From: njs at pobox.com (Nathaniel Smith) Date: Wed, 4 May 2016 02:30:09 -0700 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Wed, May 4, 2016 at 12:40 AM, Olivier Grisel wrote: > 2016-05-03 22:47 GMT+02:00 Matthew Brett : >> On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel 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 From ben.v.root at gmail.com Wed May 4 09:28:40 2016 From: ben.v.root at gmail.com (Benjamin Root) Date: Wed, 4 May 2016 09:28:40 -0400 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: 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 wrote: > On Wed, May 4, 2016 at 12:40 AM, Olivier Grisel > wrote: > > 2016-05-03 22:47 GMT+02:00 Matthew Brett : > >> On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel < > olivier.grisel at ensta.org> 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 > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue May 10 11:59:04 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 10 May 2016 11:59:04 -0400 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: Hi, On Tue, May 3, 2016 at 4:47 PM, Matthew Brett wrote: > On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel 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? I have experimented with this. It does seem that we can get away with using the system tcl / tk libraries as installed, at least on a couple of Debian systems I have. Now there's a new problem, to do with linux library namespaces. We need the _tkagg.so file to use the same libraries as the Python Tkinter package at run time. There can be more than one tcl / tk version installed on a given system, so, as things stand, we'd need to inspect the Tkinter extension modules to see what they are using, and then work out a way to use those libraries at run time. Here are the questions for the experts out there: * Can anyone think of a way of using the symbol namespace of the tkinter extension modules directly, to pick up the symbols we need rather than re-importing the libraries? * If we do discover which libraries Tkinter is using, what would be a good way of pulling in these libraries at run-time? Cheers, Matthew From njs at pobox.com Tue May 10 16:13:28 2016 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 10 May 2016 13:13:28 -0700 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On May 10, 2016 09:00, "Matthew Brett" wrote: > > Hi, > > On Tue, May 3, 2016 at 4:47 PM, Matthew Brett wrote: > > On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel 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? > > I have experimented with this. It does seem that we can get away with > using the system tcl / tk libraries as installed, at least on a couple > of Debian systems I have. > > Now there's a new problem, to do with linux library namespaces. We > need the _tkagg.so file to use the same libraries as the Python > Tkinter package at run time. There can be more than one tcl / tk > version installed on a given system, so, as things stand, we'd need to > inspect the Tkinter extension modules to see what they are using, and > then work out a way to use those libraries at run time. Here are the > questions for the experts out there: > > * Can anyone think of a way of using the symbol namespace of the > tkinter extension modules directly, to pick up the symbols we need > rather than re-importing the libraries? It would be a bit of a weird hack, but we could have _tkagg.so "link" against the tkinter extension module. The idea would be that we don't care about the symbols that the tkinter extension exports, but we'd take advantage on the fact the on ELF, linking against one .so automatically gives you not just its symbols, but also the symbols of all the libraries that it links against, transitively. This would probably look like: _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python calls this module) Before loading _tkagg.so, we use Python level introspection figure out where tkinter.so lives We add its directory to LD_LIBRARY_PATH we import _tkagg.so We take its directory back off of LD_LIBRARY_PATH Very weird, but I can't see why it wouldn't work, and probably more reliable than anything where we try to reimplement the dynamic loader's search logic ourselves. > * If we do discover which libraries Tkinter is using, what would be a > good way of pulling in these libraries at run-time? > > Cheers, > > Matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue May 10 17:26:19 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 10 May 2016 17:26:19 -0400 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: Hi, On Tue, May 10, 2016 at 4:13 PM, Nathaniel Smith wrote: > On May 10, 2016 09:00, "Matthew Brett" wrote: >> >> Hi, >> >> On Tue, May 3, 2016 at 4:47 PM, Matthew Brett >> wrote: >> > On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel >> > 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? >> >> I have experimented with this. It does seem that we can get away with >> using the system tcl / tk libraries as installed, at least on a couple >> of Debian systems I have. >> >> Now there's a new problem, to do with linux library namespaces. We >> need the _tkagg.so file to use the same libraries as the Python >> Tkinter package at run time. There can be more than one tcl / tk >> version installed on a given system, so, as things stand, we'd need to >> inspect the Tkinter extension modules to see what they are using, and >> then work out a way to use those libraries at run time. Here are the >> questions for the experts out there: >> >> * Can anyone think of a way of using the symbol namespace of the >> tkinter extension modules directly, to pick up the symbols we need >> rather than re-importing the libraries? > > It would be a bit of a weird hack, but we could have _tkagg.so "link" > against the tkinter extension module. The idea would be that we don't care > about the symbols that the tkinter extension exports, but we'd take > advantage on the fact the on ELF, linking against one .so automatically > gives you not just its symbols, but also the symbols of all the libraries > that it links against, transitively. > > This would probably look like: > > _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python calls > this module) > > Before loading _tkagg.so, we use Python level introspection figure out where > tkinter.so lives > > We add its directory to LD_LIBRARY_PATH > > we import _tkagg.so > > We take its directory back off of LD_LIBRARY_PATH > > Very weird, but I can't see why it wouldn't work, and probably more reliable > than anything where we try to reimplement the dynamic loader's search logic > ourselves. Nice - yes - it does work in a first-pass test - I'll look into automating that. Cheers, Matthew From matthew.brett at gmail.com Tue May 10 17:52:08 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 10 May 2016 17:52:08 -0400 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Tue, May 10, 2016 at 5:26 PM, Matthew Brett wrote: > Hi, > > On Tue, May 10, 2016 at 4:13 PM, Nathaniel Smith wrote: >> On May 10, 2016 09:00, "Matthew Brett" wrote: >>> >>> Hi, >>> >>> On Tue, May 3, 2016 at 4:47 PM, Matthew Brett >>> wrote: >>> > On Tue, May 3, 2016 at 5:35 AM, Olivier Grisel >>> > 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? >>> >>> I have experimented with this. It does seem that we can get away with >>> using the system tcl / tk libraries as installed, at least on a couple >>> of Debian systems I have. >>> >>> Now there's a new problem, to do with linux library namespaces. We >>> need the _tkagg.so file to use the same libraries as the Python >>> Tkinter package at run time. There can be more than one tcl / tk >>> version installed on a given system, so, as things stand, we'd need to >>> inspect the Tkinter extension modules to see what they are using, and >>> then work out a way to use those libraries at run time. Here are the >>> questions for the experts out there: >>> >>> * Can anyone think of a way of using the symbol namespace of the >>> tkinter extension modules directly, to pick up the symbols we need >>> rather than re-importing the libraries? >> >> It would be a bit of a weird hack, but we could have _tkagg.so "link" >> against the tkinter extension module. The idea would be that we don't care >> about the symbols that the tkinter extension exports, but we'd take >> advantage on the fact the on ELF, linking against one .so automatically >> gives you not just its symbols, but also the symbols of all the libraries >> that it links against, transitively. >> >> This would probably look like: >> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python calls >> this module) >> >> Before loading _tkagg.so, we use Python level introspection figure out where >> tkinter.so lives >> >> We add its directory to LD_LIBRARY_PATH >> >> we import _tkagg.so >> >> We take its directory back off of LD_LIBRARY_PATH >> >> Very weird, but I can't see why it wouldn't work, and probably more reliable >> than anything where we try to reimplement the dynamic loader's search logic >> ourselves. > > Nice - yes - it does work in a first-pass test - I'll look into automating that. Ah - except I do not believe it is possible to change the linker path for Python modules, within the Python process: http://www.gossamer-threads.com/lists/python/python/393770#393770 Ugh. Matthew From leorochael at gmail.com Tue May 10 18:09:13 2016 From: leorochael at gmail.com (Leonardo Rochael Almeida) Date: Tue, 10 May 2016 19:09:13 -0300 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On 10 May 2016 at 18:52, Matthew Brett wrote: > On Tue, May 10, 2016 at 5:26 PM, Matthew Brett > wrote: > >> [...] > >> > >> This would probably look like: > >> > >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python > calls > >> this module) > >> > >> Before loading _tkagg.so, we use Python level introspection figure out > where > >> tkinter.so lives > >> > >> We add its directory to LD_LIBRARY_PATH > >> > >> we import _tkagg.so > >> > >> We take its directory back off of LD_LIBRARY_PATH > >> > >> Very weird, but I can't see why it wouldn't work, and probably more > reliable > >> than anything where we try to reimplement the dynamic loader's search > logic > >> ourselves. > > > > Nice - yes - it does work in a first-pass test - I'll look into > automating that. > > Ah - except I do not believe it is possible to change the linker path > for Python modules, within the Python process: > > http://www.gossamer-threads.com/lists/python/python/393770#393770 I was about to point that out... On the other hand, if there is a `Tkinter` module that Python can import, just importing it will make the symbols needed the `_tkagg` module available, assuming Python calls `dlopen()` on import with RTLD_GLOBAL[1]. [1] http://man7.org/linux/man-pages/man3/dlopen.3.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Tue May 10 18:38:59 2016 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 10 May 2016 15:38:59 -0700 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida wrote: > On 10 May 2016 at 18:52, Matthew Brett wrote: >> >> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett >> wrote: >> >> [...] >> >> >> >> This would probably look like: >> >> >> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python >> >> calls >> >> this module) >> >> >> >> Before loading _tkagg.so, we use Python level introspection figure out >> >> where >> >> tkinter.so lives >> >> >> >> We add its directory to LD_LIBRARY_PATH >> >> >> >> we import _tkagg.so >> >> >> >> We take its directory back off of LD_LIBRARY_PATH >> >> >> >> Very weird, but I can't see why it wouldn't work, and probably more >> >> reliable >> >> than anything where we try to reimplement the dynamic loader's search >> >> logic >> >> ourselves. >> > >> > Nice - yes - it does work in a first-pass test - I'll look into >> > automating that. >> >> Ah - except I do not believe it is possible to change the linker path >> for Python modules, within the Python process: >> >> http://www.gossamer-threads.com/lists/python/python/393770#393770 Doh :-( > I was about to point that out... > > On the other hand, if there is a `Tkinter` module that Python can import, > just importing it will make the symbols needed the `_tkagg` module > available, assuming Python calls `dlopen()` on import with RTLD_GLOBAL[1]. > > [1] http://man7.org/linux/man-pages/man3/dlopen.3.html > But it doesn't use RTLD_GLOBAL. You can make it with sys.setdlopenflags, but this then dumps a bunch of symbols into *every* Python extension module's namespace, which is pretty risky... -n -- Nathaniel J. Smith -- https://vorpus.org From matthew.brett at gmail.com Wed May 11 09:58:51 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Wed, 11 May 2016 09:58:51 -0400 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith wrote: > On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida > wrote: >> On 10 May 2016 at 18:52, Matthew Brett wrote: >>> >>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett >>> wrote: >>> >> [...] >>> >> >>> >> This would probably look like: >>> >> >>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python >>> >> calls >>> >> this module) >>> >> >>> >> Before loading _tkagg.so, we use Python level introspection figure out >>> >> where >>> >> tkinter.so lives >>> >> >>> >> We add its directory to LD_LIBRARY_PATH >>> >> >>> >> we import _tkagg.so >>> >> >>> >> We take its directory back off of LD_LIBRARY_PATH >>> >> >>> >> Very weird, but I can't see why it wouldn't work, and probably more >>> >> reliable >>> >> than anything where we try to reimplement the dynamic loader's search >>> >> logic >>> >> ourselves. >>> > >>> > Nice - yes - it does work in a first-pass test - I'll look into >>> > automating that. >>> >>> Ah - except I do not believe it is possible to change the linker path >>> for Python modules, within the Python process: >>> >>> http://www.gossamer-threads.com/lists/python/python/393770#393770 > > Doh :-( Any other suggestions? I guess this will be a problem for the external library PEP? Matthew From leorochael at gmail.com Wed May 11 14:26:24 2016 From: leorochael at gmail.com (Leonardo Rochael Almeida) Date: Wed, 11 May 2016 15:26:24 -0300 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On 11 May 2016 at 10:58, Matthew Brett wrote: > On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith wrote: > > On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida > > wrote: > >> On 10 May 2016 at 18:52, Matthew Brett wrote: > >>> > >>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett < > matthew.brett at gmail.com> > >>> wrote: > >>> >> [...] > >>> >> > >>> >> This would probably look like: > >>> >> > >>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever > Python > >>> >> calls > >>> >> this module) > >>> >> > >>> >> Before loading _tkagg.so, we use Python level introspection figure > out > >>> >> where > >>> >> tkinter.so lives > >>> >> > >>> >> We add its directory to LD_LIBRARY_PATH > >>> >> > >>> >> we import _tkagg.so > >>> >> > >>> >> We take its directory back off of LD_LIBRARY_PATH > >>> >> > >>> >> Very weird, but I can't see why it wouldn't work, and probably more > >>> >> reliable > >>> >> than anything where we try to reimplement the dynamic loader's > search > >>> >> logic > >>> >> ourselves. > >>> > > >>> > Nice - yes - it does work in a first-pass test - I'll look into > >>> > automating that. > >>> > >>> Ah - except I do not believe it is possible to change the linker path > >>> for Python modules, within the Python process: > >>> > >>> http://www.gossamer-threads.com/lists/python/python/393770#393770 > > > > Doh :-( > > Any other suggestions? > Calling `patchelf` at runtime with the result of introspecting the `_tkinter.so` module? :-) On a more serious note, even though it would be dangerous to call `sys.setdlopenflags()` with `RTLD_GLOBAL`, we could perhaps manually call: - ctypes.CDLL("/path/to/introspected/libtk.so", DLFCN.RTLD_GLOBAL) - ctypes.CDLL("/path/to/introspected/libtcl.so", DLFCN.RTLD_GLOBAL) before importing a `_tkagg.so` with `libtk` and `libtcl` patchelf-removed (but not re-added). We would be dumping only libtcl/tk's symbols in the namespace of other python extension modules. > I guess this will be a problem for the external library PEP? > Likely, yes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Wed May 11 19:26:37 2016 From: njs at pobox.com (Nathaniel Smith) Date: Wed, 11 May 2016 16:26:37 -0700 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Wed, May 11, 2016 at 6:58 AM, Matthew Brett wrote: > On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith wrote: >> On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida >> wrote: >>> On 10 May 2016 at 18:52, Matthew Brett wrote: >>>> >>>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett >>>> wrote: >>>> >> [...] >>>> >> >>>> >> This would probably look like: >>>> >> >>>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python >>>> >> calls >>>> >> this module) >>>> >> >>>> >> Before loading _tkagg.so, we use Python level introspection figure out >>>> >> where >>>> >> tkinter.so lives >>>> >> >>>> >> We add its directory to LD_LIBRARY_PATH >>>> >> >>>> >> we import _tkagg.so >>>> >> >>>> >> We take its directory back off of LD_LIBRARY_PATH >>>> >> >>>> >> Very weird, but I can't see why it wouldn't work, and probably more >>>> >> reliable >>>> >> than anything where we try to reimplement the dynamic loader's search >>>> >> logic >>>> >> ourselves. >>>> > >>>> > Nice - yes - it does work in a first-pass test - I'll look into >>>> > automating that. >>>> >>>> Ah - except I do not believe it is possible to change the linker path >>>> for Python modules, within the Python process: >>>> >>>> http://www.gossamer-threads.com/lists/python/python/393770#393770 >> >> Doh :-( > > Any other suggestions? One option is to just drop tk support from the wheels, and stick with Qt or GTK. Super annoying because it would mean we need to sort out the Qt-or-GTK wheel situation too, but I guess we have to do that anyway, and this would just move it up the priority list? Barring that, I guess the plan of converting _tkagg.so to ctypes is the only option. I assume the matplotlib devs are very motivated to get linux wheels -- maybe we can convince them to implement this? :-) > I guess this will be a problem for the external library PEP? (It's not a PEP) For the external library proposal on Linux it's annoying but I think we're okay -- instead of adjusting LD_LIBRARY_PATH we can fall back to using the "preload trick", like on Windows. Basically exploiting our old friend this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19884 :-). And on Windows I know we can use the preload trick, so that's okay. What I'm really worried about now is OS X -- we need at least one of these to work: {runtime changes to DYLD_LIBRARY_PATH, the preloading trick}. Do they? If not then we have a serious problem :-/ -n -- Nathaniel J. Smith -- https://vorpus.org From matthew.brett at gmail.com Thu May 12 16:28:10 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 12 May 2016 16:28:10 -0400 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: Hi, On Wed, May 11, 2016 at 7:26 PM, Nathaniel Smith wrote: > On Wed, May 11, 2016 at 6:58 AM, Matthew Brett wrote: >> On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith wrote: >>> On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida >>> wrote: >>>> On 10 May 2016 at 18:52, Matthew Brett wrote: >>>>> >>>>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett >>>>> wrote: >>>>> >> [...] >>>>> >> >>>>> >> This would probably look like: >>>>> >> >>>>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever Python >>>>> >> calls >>>>> >> this module) >>>>> >> >>>>> >> Before loading _tkagg.so, we use Python level introspection figure out >>>>> >> where >>>>> >> tkinter.so lives >>>>> >> >>>>> >> We add its directory to LD_LIBRARY_PATH >>>>> >> >>>>> >> we import _tkagg.so >>>>> >> >>>>> >> We take its directory back off of LD_LIBRARY_PATH >>>>> >> >>>>> >> Very weird, but I can't see why it wouldn't work, and probably more >>>>> >> reliable >>>>> >> than anything where we try to reimplement the dynamic loader's search >>>>> >> logic >>>>> >> ourselves. >>>>> > >>>>> > Nice - yes - it does work in a first-pass test - I'll look into >>>>> > automating that. >>>>> >>>>> Ah - except I do not believe it is possible to change the linker path >>>>> for Python modules, within the Python process: >>>>> >>>>> http://www.gossamer-threads.com/lists/python/python/393770#393770 >>> >>> Doh :-( >> >> Any other suggestions? > > One option is to just drop tk support from the wheels, and stick with > Qt or GTK. Super annoying because it would mean we need to sort out > the Qt-or-GTK wheel situation too, but I guess we have to do that > anyway, and this would just move it up the priority list? > > Barring that, I guess the plan of converting _tkagg.so to ctypes is > the only option. > > I assume the matplotlib devs are very motivated to get linux wheels -- > maybe we can convince them to implement this? :-) > >> I guess this will be a problem for the external library PEP? > > (It's not a PEP) > > For the external library proposal on Linux it's annoying but I think > we're okay -- instead of adjusting LD_LIBRARY_PATH we can fall back to > using the "preload trick", like on Windows. Basically exploiting our > old friend this bug: > https://sourceware.org/bugzilla/show_bug.cgi?id=19884 > :-). > > And on Windows I know we can use the preload trick, so that's okay. > > What I'm really worried about now is OS X -- we need at least one of > these to work: {runtime changes to DYLD_LIBRARY_PATH, the preloading > trick}. Do they? If not then we have a serious problem :-/ Sorry - writing in haste - but I believe that OSX does have preload trick. There's something called the "install name" : http://matthew-brett.github.io/docosx/mac_runtime_link.html#the-install-name - this is the name the library declares. I believe (but I am not sure) that once a library is loaded with a given "install name" then no further libraries with the same required install name get loaded... Cheers, Matthew From matthew.brett at gmail.com Tue May 17 16:23:07 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 17 May 2016 16:23:07 -0400 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: Hi, On Wed, May 11, 2016 at 2:26 PM, Leonardo Rochael Almeida wrote: > On 11 May 2016 at 10:58, Matthew Brett wrote: >> >> On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith wrote: >> > On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida >> > wrote: >> >> On 10 May 2016 at 18:52, Matthew Brett wrote: >> >>> >> >>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett >> >>> >> >>> wrote: >> >>> >> [...] >> >>> >> >> >>> >> This would probably look like: >> >>> >> >> >>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever >> >>> >> Python >> >>> >> calls >> >>> >> this module) >> >>> >> >> >>> >> Before loading _tkagg.so, we use Python level introspection figure >> >>> >> out >> >>> >> where >> >>> >> tkinter.so lives >> >>> >> >> >>> >> We add its directory to LD_LIBRARY_PATH >> >>> >> >> >>> >> we import _tkagg.so >> >>> >> >> >>> >> We take its directory back off of LD_LIBRARY_PATH >> >>> >> >> >>> >> Very weird, but I can't see why it wouldn't work, and probably more >> >>> >> reliable >> >>> >> than anything where we try to reimplement the dynamic loader's >> >>> >> search >> >>> >> logic >> >>> >> ourselves. >> >>> > >> >>> > Nice - yes - it does work in a first-pass test - I'll look into >> >>> > automating that. >> >>> >> >>> Ah - except I do not believe it is possible to change the linker path >> >>> for Python modules, within the Python process: >> >>> >> >>> http://www.gossamer-threads.com/lists/python/python/393770#393770 >> > >> > Doh :-( >> >> Any other suggestions? > > > Calling `patchelf` at runtime with the result of introspecting the > `_tkinter.so` module? :-) > > On a more serious note, even though it would be dangerous to call > `sys.setdlopenflags()` with `RTLD_GLOBAL`, we could perhaps manually call: > > ctypes.CDLL("/path/to/introspected/libtk.so", DLFCN.RTLD_GLOBAL) > ctypes.CDLL("/path/to/introspected/libtcl.so", DLFCN.RTLD_GLOBAL) > > before importing a `_tkagg.so` with `libtk` and `libtcl` patchelf-removed > (but not re-added). > > We would be dumping only libtcl/tk's symbols in the namespace of other > python extension modules. I have implemented dlopen dynamic loading of the TCL / Tk functions from the Python tkinter extension module here : https://github.com/matplotlib/matplotlib/pull/6442 It appears to work. I'd love any feedback y'all can offer. Cheers, Matthew From matthew.brett at gmail.com Mon May 23 12:53:05 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 23 May 2016 12:53:05 -0400 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Tue, May 17, 2016 at 4:23 PM, Matthew Brett wrote: > Hi, > > On Wed, May 11, 2016 at 2:26 PM, Leonardo Rochael Almeida > wrote: >> On 11 May 2016 at 10:58, Matthew Brett wrote: >>> >>> On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith wrote: >>> > On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida >>> > wrote: >>> >> On 10 May 2016 at 18:52, Matthew Brett wrote: >>> >>> >>> >>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett >>> >>> >>> >>> wrote: >>> >>> >> [...] >>> >>> >> >>> >>> >> This would probably look like: >>> >>> >> >>> >>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever >>> >>> >> Python >>> >>> >> calls >>> >>> >> this module) >>> >>> >> >>> >>> >> Before loading _tkagg.so, we use Python level introspection figure >>> >>> >> out >>> >>> >> where >>> >>> >> tkinter.so lives >>> >>> >> >>> >>> >> We add its directory to LD_LIBRARY_PATH >>> >>> >> >>> >>> >> we import _tkagg.so >>> >>> >> >>> >>> >> We take its directory back off of LD_LIBRARY_PATH >>> >>> >> >>> >>> >> Very weird, but I can't see why it wouldn't work, and probably more >>> >>> >> reliable >>> >>> >> than anything where we try to reimplement the dynamic loader's >>> >>> >> search >>> >>> >> logic >>> >>> >> ourselves. >>> >>> > >>> >>> > Nice - yes - it does work in a first-pass test - I'll look into >>> >>> > automating that. >>> >>> >>> >>> Ah - except I do not believe it is possible to change the linker path >>> >>> for Python modules, within the Python process: >>> >>> >>> >>> http://www.gossamer-threads.com/lists/python/python/393770#393770 >>> > >>> > Doh :-( >>> >>> Any other suggestions? >> >> >> Calling `patchelf` at runtime with the result of introspecting the >> `_tkinter.so` module? :-) >> >> On a more serious note, even though it would be dangerous to call >> `sys.setdlopenflags()` with `RTLD_GLOBAL`, we could perhaps manually call: >> >> ctypes.CDLL("/path/to/introspected/libtk.so", DLFCN.RTLD_GLOBAL) >> ctypes.CDLL("/path/to/introspected/libtcl.so", DLFCN.RTLD_GLOBAL) >> >> before importing a `_tkagg.so` with `libtk` and `libtcl` patchelf-removed >> (but not re-added). >> >> We would be dumping only libtcl/tk's symbols in the namespace of other >> python extension modules. > > I have implemented dlopen dynamic loading of the TCL / Tk functions > from the Python tkinter extension module here : > https://github.com/matplotlib/matplotlib/pull/6442 > > It appears to work. I'd love any feedback y'all can offer. I patched matplotlib 1.5.1 with a version of the PR at [1] to build the wheels using the script at [2] and travis-ci repo build at [3]. The built wheels are up at http://ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com/ for testing. They work for me, for example doing tkagg animations. Cheers, Matthew [1] https://github.com/matplotlib/matplotlib/pull/6442 [2] https://github.com/matthew-brett/manylinux-builds/blob/master/build_matplotlibs.sh [3] https://travis-ci.org/matthew-brett/manylinux-builds/builds/132304156 From matthew.brett at gmail.com Mon May 23 15:37:54 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 23 May 2016 15:37:54 -0400 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Mon, May 23, 2016 at 12:53 PM, Matthew Brett wrote: > On Tue, May 17, 2016 at 4:23 PM, Matthew Brett wrote: >> Hi, >> >> On Wed, May 11, 2016 at 2:26 PM, Leonardo Rochael Almeida >> wrote: >>> On 11 May 2016 at 10:58, Matthew Brett wrote: >>>> >>>> On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith wrote: >>>> > On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida >>>> > wrote: >>>> >> On 10 May 2016 at 18:52, Matthew Brett wrote: >>>> >>> >>>> >>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett >>>> >>> >>>> >>> wrote: >>>> >>> >> [...] >>>> >>> >> >>>> >>> >> This would probably look like: >>>> >>> >> >>>> >>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever >>>> >>> >> Python >>>> >>> >> calls >>>> >>> >> this module) >>>> >>> >> >>>> >>> >> Before loading _tkagg.so, we use Python level introspection figure >>>> >>> >> out >>>> >>> >> where >>>> >>> >> tkinter.so lives >>>> >>> >> >>>> >>> >> We add its directory to LD_LIBRARY_PATH >>>> >>> >> >>>> >>> >> we import _tkagg.so >>>> >>> >> >>>> >>> >> We take its directory back off of LD_LIBRARY_PATH >>>> >>> >> >>>> >>> >> Very weird, but I can't see why it wouldn't work, and probably more >>>> >>> >> reliable >>>> >>> >> than anything where we try to reimplement the dynamic loader's >>>> >>> >> search >>>> >>> >> logic >>>> >>> >> ourselves. >>>> >>> > >>>> >>> > Nice - yes - it does work in a first-pass test - I'll look into >>>> >>> > automating that. >>>> >>> >>>> >>> Ah - except I do not believe it is possible to change the linker path >>>> >>> for Python modules, within the Python process: >>>> >>> >>>> >>> http://www.gossamer-threads.com/lists/python/python/393770#393770 >>>> > >>>> > Doh :-( >>>> >>>> Any other suggestions? >>> >>> >>> Calling `patchelf` at runtime with the result of introspecting the >>> `_tkinter.so` module? :-) >>> >>> On a more serious note, even though it would be dangerous to call >>> `sys.setdlopenflags()` with `RTLD_GLOBAL`, we could perhaps manually call: >>> >>> ctypes.CDLL("/path/to/introspected/libtk.so", DLFCN.RTLD_GLOBAL) >>> ctypes.CDLL("/path/to/introspected/libtcl.so", DLFCN.RTLD_GLOBAL) >>> >>> before importing a `_tkagg.so` with `libtk` and `libtcl` patchelf-removed >>> (but not re-added). >>> >>> We would be dumping only libtcl/tk's symbols in the namespace of other >>> python extension modules. >> >> I have implemented dlopen dynamic loading of the TCL / Tk functions >> from the Python tkinter extension module here : >> https://github.com/matplotlib/matplotlib/pull/6442 >> >> It appears to work. I'd love any feedback y'all can offer. > > I patched matplotlib 1.5.1 with a version of the PR at [1] to build > the wheels using the script at [2] and travis-ci repo build at [3]. > > The built wheels are up at > http://ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com/ > for testing. > > They work for me, for example doing tkagg animations. Travis testing of these wheels, and some errors, reported at https://github.com/matplotlib/matplotlib/issues/6469 Cheers, Matthew From olivier.grisel at ensta.org Tue May 24 08:33:53 2016 From: olivier.grisel at ensta.org (Olivier Grisel) Date: Tue, 24 May 2016 14:33:53 +0200 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: 2016-05-23 18:53 GMT+02:00 Matthew Brett : > > I patched matplotlib 1.5.1 with a version of the PR at [1] to build > the wheels using the script at [2] and travis-ci repo build at [3]. > > The built wheels are up at > http://ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com/ > for testing. I did some basic testing and it works for me as well. Note: if you want to install them you need to tell pip to trust that host: pip install -U --no-index \ --trusted-host=ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com\ -f http://ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com/\ matplotlib System: ubuntu 14.04, python 3.5.1 from the deadsnakes ppa. -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel From matthew.brett at gmail.com Tue May 24 11:28:23 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 24 May 2016 11:28:23 -0400 Subject: [Wheel-builders] [Matplotlib-devel] Manylinux external library test case - matplotlib, tk In-Reply-To: References: Message-ID: On Mon, May 23, 2016 at 3:37 PM, Matthew Brett wrote: > On Mon, May 23, 2016 at 12:53 PM, Matthew Brett wrote: >> On Tue, May 17, 2016 at 4:23 PM, Matthew Brett wrote: >>> Hi, >>> >>> On Wed, May 11, 2016 at 2:26 PM, Leonardo Rochael Almeida >>> wrote: >>>> On 11 May 2016 at 10:58, Matthew Brett wrote: >>>>> >>>>> On Tue, May 10, 2016 at 6:38 PM, Nathaniel Smith wrote: >>>>> > On Tue, May 10, 2016 at 3:09 PM, Leonardo Rochael Almeida >>>>> > wrote: >>>>> >> On 10 May 2016 at 18:52, Matthew Brett wrote: >>>>> >>> >>>>> >>> On Tue, May 10, 2016 at 5:26 PM, Matthew Brett >>>>> >>> >>>>> >>> wrote: >>>>> >>> >> [...] >>>>> >>> >> >>>>> >>> >> This would probably look like: >>>>> >>> >> >>>>> >>> >> _tkagg.so has a DT_NEEDED entry naming tkinter.so (or whatever >>>>> >>> >> Python >>>>> >>> >> calls >>>>> >>> >> this module) >>>>> >>> >> >>>>> >>> >> Before loading _tkagg.so, we use Python level introspection figure >>>>> >>> >> out >>>>> >>> >> where >>>>> >>> >> tkinter.so lives >>>>> >>> >> >>>>> >>> >> We add its directory to LD_LIBRARY_PATH >>>>> >>> >> >>>>> >>> >> we import _tkagg.so >>>>> >>> >> >>>>> >>> >> We take its directory back off of LD_LIBRARY_PATH >>>>> >>> >> >>>>> >>> >> Very weird, but I can't see why it wouldn't work, and probably more >>>>> >>> >> reliable >>>>> >>> >> than anything where we try to reimplement the dynamic loader's >>>>> >>> >> search >>>>> >>> >> logic >>>>> >>> >> ourselves. >>>>> >>> > >>>>> >>> > Nice - yes - it does work in a first-pass test - I'll look into >>>>> >>> > automating that. >>>>> >>> >>>>> >>> Ah - except I do not believe it is possible to change the linker path >>>>> >>> for Python modules, within the Python process: >>>>> >>> >>>>> >>> http://www.gossamer-threads.com/lists/python/python/393770#393770 >>>>> > >>>>> > Doh :-( >>>>> >>>>> Any other suggestions? >>>> >>>> >>>> Calling `patchelf` at runtime with the result of introspecting the >>>> `_tkinter.so` module? :-) >>>> >>>> On a more serious note, even though it would be dangerous to call >>>> `sys.setdlopenflags()` with `RTLD_GLOBAL`, we could perhaps manually call: >>>> >>>> ctypes.CDLL("/path/to/introspected/libtk.so", DLFCN.RTLD_GLOBAL) >>>> ctypes.CDLL("/path/to/introspected/libtcl.so", DLFCN.RTLD_GLOBAL) >>>> >>>> before importing a `_tkagg.so` with `libtk` and `libtcl` patchelf-removed >>>> (but not re-added). >>>> >>>> We would be dumping only libtcl/tk's symbols in the namespace of other >>>> python extension modules. >>> >>> I have implemented dlopen dynamic loading of the TCL / Tk functions >>> from the Python tkinter extension module here : >>> https://github.com/matplotlib/matplotlib/pull/6442 >>> >>> It appears to work. I'd love any feedback y'all can offer. >> >> I patched matplotlib 1.5.1 with a version of the PR at [1] to build >> the wheels using the script at [2] and travis-ci repo build at [3]. >> >> The built wheels are up at >> http://ccdd0ebb5a931e58c7c5-aae005c4999d7244ac63632f8b80e089.r77.cf2.rackcdn.com/ >> for testing. >> >> They work for me, for example doing tkagg animations. > > Travis testing of these wheels, and some errors, reported at > https://github.com/matplotlib/matplotlib/issues/6469 Thanks Olivier for testing. Thomas Caswell gave me the pointers I needed to fix the test failures, tests now passing at : https://travis-ci.org/matthew-brett/manylinux-testing/builds/132577898 I think these wheels are now ready to ship - MPL issue at : https://github.com/matplotlib/matplotlib/issues/6473 Cheers, Matthew From rmcgibbo at gmail.com Wed May 25 10:43:29 2016 From: rmcgibbo at gmail.com (Robert T. McGibbon) Date: Wed, 25 May 2016 10:43:29 -0400 Subject: [Wheel-builders] Auditwheel release Message-ID: Hi all, I pushed a new cut of auditwheel (latest master) to PyPI as auditwheel 1.4 this morning. It should be out as part of the docker images soon. Please file an issue on github or respond here if you run into any problems. -- -Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanv at berkeley.edu Wed May 25 12:59:42 2016 From: stefanv at berkeley.edu (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=) Date: Wed, 25 May 2016 16:59:42 +0000 Subject: [Wheel-builders] Auditwheel release In-Reply-To: References: Message-ID: Hi Robert Thanks for the new release! I am curious to know whether it addresses any of these issues: https://github.com/pypa/auditwheel/issues St?fan On Wed, 25 May 2016 at 07:43 Robert T. McGibbon wrote: > Hi all, > > I pushed a new cut of auditwheel (latest master) to PyPI as auditwheel 1.4 > this morning. It should be out as part of the docker images soon. Please > file an issue on github or respond here if you run into any problems. > > -- > -Robert > _______________________________________________ > Wheel-builders mailing list > Wheel-builders at python.org > https://mail.python.org/mailman/listinfo/wheel-builders > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmcgibbo at gmail.com Wed May 25 13:16:14 2016 From: rmcgibbo at gmail.com (Robert T. McGibbon) Date: Wed, 25 May 2016 13:16:14 -0400 Subject: [Wheel-builders] Auditwheel release In-Reply-To: References: Message-ID: No, it doesn't. Those are all outstanding issues on the master branch. -Robert On Wed, May 25, 2016 at 12:59 PM, St?fan van der Walt wrote: > Hi Robert > > Thanks for the new release! I am curious to know whether it addresses any > of these issues: > > https://github.com/pypa/auditwheel/issues > > St?fan > > On Wed, 25 May 2016 at 07:43 Robert T. McGibbon > wrote: > >> Hi all, >> >> I pushed a new cut of auditwheel (latest master) to PyPI as auditwheel >> 1.4 this morning. It should be out as part of the docker images soon. >> Please file an issue on github or respond here if you run into any problems. >> >> -- >> -Robert >> _______________________________________________ >> Wheel-builders mailing list >> Wheel-builders at python.org >> https://mail.python.org/mailman/listinfo/wheel-builders >> > -- -Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Mon May 30 14:31:22 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 30 May 2016 11:31:22 -0700 Subject: [Wheel-builders] warehouse uploads - anyone got these working? Message-ID: Hi, I've been trying to upload packages to warehouse with this `~/.pypirc`: [distutils] index-servers = pypi warehouse [pypi] username: username password: password [warehouse] repository: https://warehouse.python.org/pypi username: username password: password [server-login] username: username password: password and this command (lastest twine): twine upload -r warehouse -s numpy-1.11.1rc1-cp27-cp27m-manylinux1_x86_64.whl but I get: ConnectionError: ('Connection aborted.', error(32, 'Broken pipe')) Is this the right incantation? Has anyone got this working to their satisfaction? Cheers, Matthew From dana.powers at gmail.com Mon May 30 14:59:04 2016 From: dana.powers at gmail.com (Dana Powers) Date: Mon, 30 May 2016 11:59:04 -0700 Subject: [Wheel-builders] warehouse uploads - anyone got these working? In-Reply-To: References: Message-ID: I have never uploaded to warehouse, but checking the url shows: https://warehouse.python.org/pypi -> 301 redirect to https://pypi.io/pypi https://pypi.io/pypi -> 404 Have you tried dropping `/pypi` from the repository url ? -Dana On Mon, May 30, 2016 at 11:31 AM, Matthew Brett wrote: > Hi, > > I've been trying to upload packages to warehouse with this `~/.pypirc`: > > [distutils] > index-servers = > pypi > warehouse > > [pypi] > username: username > password: password > > [warehouse] > repository: https://warehouse.python.org/pypi > username: username > password: password > > [server-login] > username: username > password: password > > and this command (lastest twine): > > twine upload -r warehouse -s numpy-1.11.1rc1-cp27-cp27m-manylinux1_x86_64.whl > > but I get: > > ConnectionError: ('Connection aborted.', error(32, 'Broken pipe')) > > Is this the right incantation? Has anyone got this working to their > satisfaction? > > Cheers, > > Matthew > _______________________________________________ > Wheel-builders mailing list > Wheel-builders at python.org > https://mail.python.org/mailman/listinfo/wheel-builders From matthew.brett at gmail.com Mon May 30 15:16:09 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 30 May 2016 12:16:09 -0700 Subject: [Wheel-builders] warehouse uploads - anyone got these working? In-Reply-To: References: Message-ID: On Mon, May 30, 2016 at 11:59 AM, Dana Powers wrote: > I have never uploaded to warehouse, but checking the url shows: > > https://warehouse.python.org/pypi -> 301 redirect to https://pypi.io/pypi > > https://pypi.io/pypi -> 404 > > Have you tried dropping `/pypi` from the repository url ? I tried it before, and again just now - I get the same error. If I put the url as https://pypi.io I get: HTTPError: 405 Client Error: Method Not Allowed for url: https://pypi.io/ Cheers, Matthew From donald at stufft.io Mon May 30 16:41:59 2016 From: donald at stufft.io (Donald Stufft) Date: Mon, 30 May 2016 16:41:59 -0400 Subject: [Wheel-builders] warehouse uploads - anyone got these working? In-Reply-To: References: Message-ID: <0EC17E62-DF48-4083-A446-81734E8F29AB@stufft.io> you want repository: https://upload.pypi.io/legacy/ > On May 30, 2016, at 3:16 PM, Matthew Brett wrote: > > On Mon, May 30, 2016 at 11:59 AM, Dana Powers wrote: >> I have never uploaded to warehouse, but checking the url shows: >> >> https://warehouse.python.org/pypi -> 301 redirect to https://pypi.io/pypi >> >> https://pypi.io/pypi -> 404 >> >> Have you tried dropping `/pypi` from the repository url ? > > I tried it before, and again just now - I get the same error. > > If I put the url as https://pypi.io I get: > > HTTPError: 405 Client Error: Method Not Allowed for url: https://pypi.io/ > > Cheers, > > Matthew > _______________________________________________ > Wheel-builders mailing list > Wheel-builders at python.org > https://mail.python.org/mailman/listinfo/wheel-builders ? Donald Stufft