After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 591745 - gtk.gdk.get_pixels_array should use PEP3118 buffer protocol
gtk.gdk.get_pixels_array should use PEP3118 buffer protocol
Status: RESOLVED WONTFIX
Product: pygtk
Classification: Bindings
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2009-08-13 20:54 UTC by Adam Jackson
Modified: 2018-08-17 13:39 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Adam Jackson 2009-08-13 20:54:43 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.
Comment 1 John Finlay 2009-08-14 02:42:59 UTC
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?
Comment 2 Gian Mario Tagliaretti 2009-08-14 07:24:24 UTC
(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.

Comment 3 Adam Jackson 2009-08-18 20:05:56 UTC
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.
Comment 4 John Finlay 2009-08-18 22:30:23 UTC
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?
Comment 5 André Klapper 2018-08-17 13:39:55 UTC
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!