GNOME Bugzilla – Bug 591745
gtk.gdk.get_pixels_array should use PEP3118 buffer protocol
Last modified: 2018-08-17 13:39:55 UTC
pygtk2 depends on numpy (which depends on atlas) to implement just this one function, which is a rather large dependency explosion. Several people have noticed this while trying to build small OS images: https://bugs.launchpad.net/ubuntu/+source/python-numpy/+bug/309215 https://www.redhat.com/archives/fedora-devel-list/2009-August/msg00623.html PEP3118 is a generic buffer protocol in Python 2.6 and later to allow exchange between arbitrary python extensions. http://www.python.org/dev/peps/pep-3118/ pygtk2 should use this instead of numpy's array types to avoid this dependency.
I thought that this was an optional method i.e. no hard dependency on numpy is involved. I seem to recall that pygtk builds without numpy by default if not available. Was this changed?
(In reply to comment #1) > I thought that this was an optional method i.e. no hard dependency on numpy is > involved. I seem to recall that pygtk builds without numpy by default if not > available. Was this changed? you are correct John, when I changed from Numeric to Numpy I kept the dependency totally optional, you can build PyGTK without Numpy.
It is a soft dependency, in that if numpy is not installed _and_ the calling pygtk app does not call get_pixels_array, nothing bad will happen. However, apps that do call that entrypoint must have numpy installed, or they'll throw an exception. From a distribution point of view this is problematic. You can't really build pygtk without numpy support, because some apps do use this API, and you want them to work with the system pygtk. You therefore (in the rpm terminology) have to say Requires: numpy in some package or other. You can add that requirement either in pygtk2 itself, or in all the packages that call this API. The former is undesirable for space reasons (and sort of defeats the purpose of having made it a soft dep in the code). The latter is undesirable because it's more typing and easy to forget to do. Nonetheless we're moving towards doing the latter in Fedora because the space argument wins. If, however, the pixel array so returned was a PEP3118 buffer, then it's my understanding that the numpy dep would be completely eliminated from pygtk, without significantly changing the interface for the caller.
My thinking is that if an app relies on an optional interface then it should make sure at runtime the interface is available and either fail or provide an alternative. If get_pixels_array() was changed to use PEP3118 how would that work?
pygtk is not under active development anymore and had its last code changes in 2013. Its codebase has been archived: https://gitlab.gnome.org/Archive/pygtk/commits/master PyGObject at https://gitlab.gnome.org/GNOME/pygobject is its successor. See https://pygobject.readthedocs.io/en/latest/guide/porting.html for porting info. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Feel free to open a task in GNOME Gitlab if the issue described in this task still applies to a recent version of PyGObject. Thanks!