Port all pyexiv2 apps to GExiv2

Just waiting for upstream approval of my patch, here: https://github.com/tiagovaz/flickrbackup/pull/1

Branch lp:~robru/smartshine/gexiv2 contains the port to GExiv2 for that project.

Patch for lazygal has been emailed privately to it's maintainer.

This patch ports lazygal from pyexiv2 to GExiv2, with zero test failures.

Patch for creepy can be found at this github pull request: https://github.com/ilektrojohn/creepy/pull/25

The attachment "port-lazygal-to-gexiv2.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Porting of Rapid Photo Downloader is blocked because this app is still using all the old static gtk/gobject bindings, which conflict with the gobject introspection magic that is necessary to import GExiv2. The code that implements GExiv2 for rapid photo downloader is largely done, but it won't actually run correctly until the rest of rpd gets ported to the new introspection bindings.

 I understand for all practical purposes, the introspection bindings depend
on python 3 and GTK 3. Rapid Photo Downloader currently depends on PIL,
which is not yet ported to Python 3. Ripping out PIL, converting to GTK3 +
introspection + python3 seems like a massive undertaking! And all this with
no actual practical end benefit for the user. On the other hand, if gphoto2
has an introspection binding, that would be a benefit, because finally the
user might be able to download from a camera without the nightmare of the
buggy gphoto2/gvfs bindings.

On Tue, Jan 1, 2013 at 4:02 PM, Robert Bruce Park <<email address hidden>
> wrote:

> Porting of Rapid Photo Downloader is blocked because this app is still
> using all the old static gtk/gobject bindings, which conflict with the
> gobject introspection magic that is necessary to import GExiv2. The code
> that implements GExiv2 for rapid photo downloader is largely done, but
> it won't actually run correctly until the rest of rpd gets ported to the
> new introspection bindings.
>
> ** Changed in: rapid
> Status: In Progress => Confirmed
>
> --
> You received this bug notification because you are subscribed to Rapid
> Photo Downloader.
> https://bugs.launchpad.net/bugs/1074028
>
> Title:
> Port all pyexiv2 apps to GExiv2
>
> Status in Nautilus Image Manipulator:
> Fix Committed
> Status in pyexiv2, a python binding to exiv2:
> Triaged
> Status in Rapid Photo Downloader:
> Confirmed
> Status in SmartShine - automation for the photographers:
> Fix Committed
> Status in “creepy” package in Ubuntu:
> Fix Committed
> Status in “flickrbackup” package in Ubuntu:
> Fix Committed
> Status in “gexiv2” package in Ubuntu:
> Triaged
> Status in “gramps” package in Ubuntu:
> Triaged
> Status in “lazygal” package in Ubuntu:
> Fix Committed
> Status in “phatch” package in Ubuntu:
> Triaged
> Status in “pyexiv2” package in Ubuntu:
> Triaged
> Status in “videoporama” package in Ubuntu:
> Triaged
>
> Bug description:
> I have spoken directly with the maintainer of pyexiv2 and we have
> agreed that pyexiv2 is an abandoned project that will never support
> Python3. Therefore, anything that depends on pyexiv2 is going to be
> stuck on Python 2 until they port to GExiv2. GExiv2 is a clear winner
> in terms of simplicity, and maintainability.
>
> Packages marked as affected by this bug were designated so because
> they have a dependency on the pyexiv2 package. They will need to be
> ported to GExiv2 before they can be ported to Python 3. Here is the
> popcon data for these packages, which may hopefully allow us to
> prioritize this work by installation popularity:
>
> #rank name inst vote old recent no-files
> 6692 gramps 41836 534 41095 198 9
> 8296 phatch-cli 26266 734 25209 309 14
> 13025 videoporama 8766 120 8602 39 5
> 16897 rapid-photo-downloader 4683 174 4403 97 9
> 19941 nautilus-image-manipulator 3054 164 2816 73 1
> 35392 creepy 591 11 563 17 0
> 36572 ...

No, the introspection code has been carefully constructed to work excellently with both python 2 and python 3. The static bindings only support python 2, so sticking with the static bindings is holding you back. Porting to introspection doesn't force you to also port to python 3 immediately, what it does is *allows* you to port to Python 3 at your leisure.

The benefit to your users is that your application will continue to exist. Python 2 and GTK 2 are going away. Sure, it might be years before they're truly gone, but it will happen eventually. Imagine for a moment if your application only ran with Python 1 and GTK 1. Nobody would even be able to run it because nobody packages those old versions anymore. They're unsupported, unmaintained, and if you found a bug in the APIs, it would simply never get fixed. Python 2 and GTK 2 are slowly moving in that direction and if you don't port away from them, users will eventually lose the ability to run your program as distros stop shipping those versions.

I am not familiar with gphoto2 specifically, but yes, the introspection bindings are well maintained and if you find bugs in them, you can reasonably expect to report those and get them fixed. So yes, you'll be able to get away from the 'nightmare' of unmaintained, buggy bindings.

According to their website, Videoporama is abandoned, and superceded by an alternate project written in C++.

Not having to also move to python 3 does make it easier. I understand that
I would need to completely redo the glade files to move to GTK3 - is that
correct? Based on other projects, the time the transition would take in
hours would be how much? Am I looking at one week of full time work, or
more like 2 weeks, or 4 weeks or more?

I've checked the gphoto2 page, and as yet there are no introspection
bindings for it. The gvfs/libgphoto2 code has been broken since it was
first developed - it works with some cameras, and not at all with others.
It seems the Gnome developers simply do not have access to a sufficient
range of cameras, so any bugs reported are apparently not fixed. Users of
Rapid Photo Downloader blame my program, of course! There is no python
binding to libgphoto2. I guess the Shotwell developers wrote their own
wrapper code for vala.

On Tue, Jan 1, 2013 at 4:46 PM, Robert Bruce Park <<email address hidden>
> wrote:

> No, the introspection code has been carefully constructed to work
> excellently with both python 2 and python 3. The static bindings only
> support python 2, so sticking with the static bindings is holding you
> back. Porting to introspection doesn't force you to also port to python
> 3 immediately, what it does is *allows* you to port to Python 3 at your
> leisure.
>
> The benefit to your users is that your application will continue to
> exist. Python 2 and GTK 2 are going away. Sure, it might be years before
> they're truly gone, but it will happen eventually. Imagine for a moment
> if your application only ran with Python 1 and GTK 1. Nobody would even
> be able to run it because nobody packages those old versions anymore.
> They're unsupported, unmaintained, and if you found a bug in the APIs,
> it would simply never get fixed. Python 2 and GTK 2 are slowly moving in
> that direction and if you don't port away from them, users will
> eventually lose the ability to run your program as distros stop shipping
> those versions.
>
> I am not familiar with gphoto2 specifically, but yes, the introspection
> bindings are well maintained and if you find bugs in them, you can
> reasonably expect to report those and get them fixed. So yes, you'll be
> able to get away from the 'nightmare' of unmaintained, buggy bindings.
>
> --
> You received this bug notification because you are subscribed to Rapid
> Photo Downloader.
> https://bugs.launchpad.net/bugs/1074028
>
> Title:
> Port all pyexiv2 apps to GExiv2
>
> Status in Nautilus Image Manipulator:
> Fix Committed
> Status in pyexiv2, a python binding to exiv2:
> Triaged
> Status in Rapid Photo Downloader:
> Confirmed
> Status in SmartShine - automation for the photographers:
> Fix Committed
> Status in “creepy” package in Ubuntu:
> Fix Committed
> Status in “flickrbackup” package in Ubuntu:
> Fix Committed
> Status in “gexiv2” package in Ubuntu:
> Triaged
> Status in “gramps” package in Ubuntu:
> Triaged
> Status in “lazygal” package in Ubuntu:
> Fix Committed
> Status in “phatch” package in Ubuntu:
> Triaged
> Status in “pyexiv2” package in Ubuntu:
> Triaged
> Status in “videoporama” package in Ubuntu:
> Triaged
>
> Bug description:
> I have s...

You're right, libglade is also obsolete and you'll need to convert to GtkBuilder. Fortunately there's a script that can do that conversion for you easily. See here: http://www.micahcarrick.com/gtk-builder-libglade-faq.html So that should be a relatively small part of the overall effort.

Tough to estimate how much work it would be. Your project is quite a bit larger than most of the others also tagged on this bug... I expect you could do it within a couple weeks of full-time effort. Fortunately there are conversion scripts that can help with the port to introspection, but it's not quite as complete as the one for gtkbuilder, so there is still some manual effort involved in that.

As for gphoto2, I just don't have any experience with that, sorry. Sounds buggy, I'd avoid it if possible ;-)

Merged in Nautilus Image Manipulator in r194 (will be released with 1.2)

Released with Nautilus Image Manipulator v1.2

This bug was fixed in the package lazygal - 0.8-1

---------------
lazygal (0.8-1) unstable; urgency=low

  [ Michal Čihař ]
  * New upstream release.
    - Uses new Genshi templates (Closes: #696682).
    - Correctly handles wronly encoded artist in EXIF (Closes: #696648).
    - Uses GExiv2 (LP: #1074028).
  * Depend on GExiv2 instead of pyexiv2.
  * Bump standards to 3.9.4.
  * Use debhelper 9.

  [ Jakub Wilk ]
  * Use canonical URIs for Vcs-* fields.

 -- Michal Čihař <email address hidden> Thu, 06 Jun 2013 12:05:08 +0200

Gramps upstream have switched to GExiv2 and this change has been released in Version 4.0.0.
http://www.gramps-project.org/bugs/view.php?id=6408