GExiv2 python wrapper broken

[Corey Goldberg]

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

[Jim Nelson (yorba-jim)]

Robert, do you have any suggestions?

[Corey Goldberg (coreygoldberg)]

bump.
this is still broken in latest Trusty image.

[Martin Pitt (pitti)]

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).

[Martin Pitt (pitti)]

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.

[Jim Nelson (yorba-jim)]

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

[Launchpad Janitor (janitor)]

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

[David Fischer (david-fischer-ch)]

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')"

[Simon Feltman (s-feltman)]

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.

[Alexey Bazhin (baz-irc)]

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

[James (jet57)]

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.

[Jim Nelson (yorba-jim)]

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.

[Robert Bruce Park (robru)]

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