On 04.02.2016 06:07 PM, Ondřej Grover wrote:
> Thank you for looking into this.
> 
> On Thu, Feb 4, 2016 at 5:49 PM, Mihai Moldovan <ionic@ionic.de
> <mailto:ionic@ionic.de>> wrote:
> 
>     I've been looking around for a way to actually rollback a failing module import
>     and came up with zit.
> 
> AFAIK that's not really possible in Python as of writing this, especially with
> complicated binary modules.
> I think a solution might be to abandon the common Python EAFP idiom, because it
> assumes graceful failure without such ugly side-effects. However, I'm not sure
> what the LBYL alternative is in this case. But I think there should be one,
> possibly loading just some high-level gi module to list available APIs?

Probably not.

In a new python2 interpreter, try this:

import sys
print sys.modules
import gi.repository
print sys.modules

I guess gi.repository is the only module that could be used to query additional
modules (like Notify.)

The modules list explodes. With GI, we end up in GI hell. And there's no exit.
Ever. Again.


I'd rather suggest the following: another try block, looking for pynotify2.

On Debian, I'd switch the dependencies to use gir1.2-notify-0.7 and python-gi,
or python-notify2 (dropping python-notify completely), while *SUSE, EPEL and
Fedora will continue depending upon the GI modules for newer versions and
pynotify for older versions (at least Fedora doesn't seem to have pynotify2.)

It should probably work as a drop-in replacement for pynotify in our case (i.e.,
we don't use any callbacks or anything fancy.)

Going forward, the deprecated gobject modules for GTK2 will likely be removed at
some point anyway and we should focus on GTK3.

Any objections?



Mihai