GExiv2 python wrapper broken

Bug #1277894 reported by Corey Goldberg
32
This bug affects 5 people
Affects Status Importance Assigned to Milestone
gexiv2 (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Ubuntu Trusty Tahr (development branch)
Release: 14.04
gir1.2-gexiv2-0.4: Installed: 0.7.0-1

I can import the Python wrapper, but when initializing a Metadata object, I get an error:
"TypeError: GObject.__init__() takes exactly 0 arguments (1 given)"

It doesn't work in both python 2.7 and 3.3.

$ python
>>> from gi.repository import GExiv2
>>> GExiv2.Metadata('foo.png')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: GObject.__init__() takes exactly 0 arguments (1 given)
>>>

$ python3
>>> from gi.repository import GExiv2
>>> GExiv2.Metadata('foo.png')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: GObject.__init__() takes exactly 0 arguments (1 given)
>>>

p.s. according to: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697204#32
the Python overrides are not installed?
however, they seem to be:

$ locate GExiv2.py
/usr/lib/python2.7/dist-packages/gi/overrides/GExiv2.py
/usr/lib/python3/dist-packages/gi/overrides/GExiv2.py

Revision history for this message
Jim Nelson (yorba-jim) wrote :

Robert, do you have any suggestions?

Revision history for this message
Corey Goldberg (coreygoldberg) wrote :

bump.
this is still broken in latest Trusty image.

Revision history for this message
Martin Pitt (pitti) wrote :

This is not a bug. Calling GObject.Type() is the general GObject constructor which you can only call with initializing properties, as keyword arguments. What you want is to explicitly call a constructor of the Metadata class. In that case there is only one, gexiv2_metadata_new(), which translates as GExiv2.Metadata.new('foo.png'), but in many cases there are several (e. g. Gtk.Button.new_with_label('label').

This might be confusing as a lot of the standard Gtk widgets *can* be called like that, as they have overrides. However, these have been deprecated at last, as they are confusing, error prone, and ambiguous (https://wiki.gnome.org/action/show/Projects/PyGObject/InitializerDeprecations).

Changed in gexiv2 (Ubuntu):
status: New → Invalid
Revision history for this message
Martin Pitt (pitti) wrote :

Sorry, I was not aware that gir1.2-gexiv2-0.4 ships an override. So the GExiv2.Metadata('foo.png') syntax ought to work as that would then invoke the override, not the GObject constructor.

Changed in gexiv2 (Ubuntu):
status: Invalid → New
Revision history for this message
Jim Nelson (yorba-jim) wrote :

Martin, as I'm not Pythonic, can you hazard a guess why the user is seeing this problem?

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gexiv2 (Ubuntu):
status: New → Confirmed
Revision history for this message
David Fischer (david-fischer-ch) wrote :

Working with Python 2.7, not Python 3.3:

    python3 -c "from gi.repository.GExiv2 import Metadata; Metadata(path='my_image.png')"

In Python 3.3:

    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: gobject `GExiv2Metadata' doesn't support property `path'

A workaround:

    python3 -c "from gi.repository.GExiv2 import Metadata; m = Metadata(); m.open_path('my_image.png')"

Revision history for this message
Simon Feltman (s-feltman) wrote :

A few debugging tips:
You can verify introspection overrides are brought in by looking at the private "_overrides_module" attribute of a library:

(this is on Fedora so Ubuntu will give a different location)
python3 -c "from gi.repository import Gtk; print(Gtk._overrides_module)"
<module 'gi.overrides.Gtk' from '/usr/lib64/python3.3/site-packages/gi/overrides/Gtk.py'>

If you do the same thing with GExiv2, you should get a similar result in terms of output. It may also be a good idea to look at the result of Gtk.py to ensure the directory GExiv2.py found with "locate" is in the same place:
python3 -c "from gi.repository import GExiv2; print(GExiv2._overrides_module)"
<module 'gi.overrides.GExiv2' from '/usr/lib64/python3.3/site-packages/gi/overrides/GExiv2.py'>

Also note Python2 and 3 will require separate installs of the overrides to their respective site-packages/dist-packages directory.

Revision history for this message
Alexey Bazhin (baz-irc) wrote :

Problem is because overriden GExiv2.py tries to import _glib which doesn't exists and not even needed.

Quick hack is to remove string "from gi import _glib" from /usr/lib/python2.7/dist-packages/gi/overrides/GExiv2.py

Revision history for this message
James (jet57) wrote :

This bug is still present in the final release of 14.04. I can confirm that Alexey's quick hack workaround appears to be successful.

Revision history for this message
Jim Nelson (yorba-jim) wrote :

As it turns out, this problem (at least, one with the same sympthoms) was discovered en masse with gexiv2 on Trusty. I've just applied a patch that fixes the problem.

I'm marking this as a duplicate of that ticket on the assumption that the problems are one and the same. gexiv2 0.10.1 will have the patch that fixes this problem. If people still have this error using 0.10.1, please comment here and we can re-open.

Revision history for this message
Robert Bruce Park (robru) wrote :

Bah! I wish I'd seen this bug when it was reported. Totally dropped the ball on this one guys, sorry.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers