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 721025 - Fails to install due to "types" module conflict with system Python
Fails to install due to "types" module conflict with system Python
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: general
Git master
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2013-12-24 22:18 UTC by Colin Watson
Modified: 2013-12-27 13:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
build: Avoid clash between gi/types.py and stdlib (2.63 KB, patch)
2013-12-24 22:21 UTC, Colin Watson
none Details | Review

Description Colin Watson 2013-12-24 22:18:42 UTC
I tried to rebuild pygobject to add support for Python 3.4 in Ubuntu, but this failed as follows:

 /bin/mkdir -p '/«PKGBUILDDIR»/debian/install-3/usr/lib/python3.4/site-packages/gi'
 /usr/bin/install -c -m 644 __init__.py types.py module.py importer.py pygtkcompat.py docstring.py '/«PKGBUILDDIR»/debian/install-3/usr/lib/python3.4/site-packages/gi'
Traceback (most recent call last):
  • File "<string>", line 2 in <module>
  • File "/usr/lib/python3.4/py_compile.py", line 6 in <module>
    import importlib._bootstrap
  • File "/usr/lib/python3.4/importlib/__init__.py", line 14 in <module>
    import types
  • File "/«PKGBUILDDIR»/build-3.4/gi/types.py", line 28 in <module>
    from . import _gobject
SystemError: Parent module '' not loaded, cannot perform relative import
make[5]: *** [install-pygiPYTHON] Error 1

Searching the web finds other reports of similar problems (e.g. http://forums.gentoo.org/viewtopic-t-966954-start-0.html) with earlier Python versions, but with earlier versions it looks as though depended on the contents of your site.py.  Now that importlib imports types in 3.4, it'll happen for everyone.

This same problem arose for dbus-python six years ago, and the solution there was to use non-recursive make for the Python modules to avoid this ambiguity.  I've implemented the same thing for pygobject, attached to this bug.
Comment 1 Colin Watson 2013-12-24 22:21:17 UTC
Created attachment 264858 [details] [review]
build: Avoid clash between gi/types.py and stdlib
Comment 2 Simon Feltman 2013-12-25 03:54:49 UTC
Adding Dieter as he seems to have had some experience with this problem as well:
https://bugs.gentoo.org/show_bug.cgi?id=487196

I was thinking we might be able to use:

from __future__ import absolute_import

within the compilation sections of our local version of "py-compile":
https://git.gnome.org/browse/pygobject/tree/m4/py-compile?id=3.11.3#n119

But I could not verify this version of py-compile is even being used (at least with some print statements).

In any event the patch looks good to me.
Comment 3 Colin Watson 2013-12-25 10:32:46 UTC
I thought about absolute_import, but it wouldn't help; if your current directory is gi, then that's on sys.path, and an import of types.py from there *is* absolute.  Besides, py-compile is running with Python 3.4 here, and absolute_import became the default and mandatory behaviour in Python 3.0.
Comment 4 Martin Pitt 2013-12-27 13:12:38 UTC
Thanks Colin! Applied.