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 726877 - gi: Remove logging.error when module import fails
gi: Remove logging.error when module import fails
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
: 687697 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-03-22 14:08 UTC by Cole Robinson
Modified: 2014-03-25 01:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gi: Remove logging.error when module import fails (1.36 KB, patch)
2014-03-22 14:08 UTC, Cole Robinson
reviewed Details | Review

Description Cole Robinson 2014-03-22 14:08:20 UTC
Recent pylint has support for inspecting gi modules. It does this by
actually performing the gi import. However, trying to import a
non-existent module triggers this error, which adds noise to the
output.

We hit this in virt-manager, where we only want to use AppIndicator3
if the package is installed.

I don't understand the usefulness of this message anyways, since
the later ImportError should be clear enough. But maybe I'm missing
something.
Comment 1 Cole Robinson 2014-03-22 14:08:21 UTC
Created attachment 272629 [details] [review]
gi: Remove logging.error when module import fails
Comment 2 Simon Feltman 2014-03-22 19:47:52 UTC
*** Bug 687697 has been marked as a duplicate of this bug. ***
Comment 3 Simon Feltman 2014-03-22 20:08:10 UTC
Review of attachment 272629 [details] [review]:

Yep, we definitely want to get rid of the extra verbosity here. Note in bug 687697 there was a discussion that instead of returning None from the import, we raise an ImportError with a better message about the typelib not being found (similar to what is being logged). This may give developers an extra hint about why they cannot import something. For example:

>>> from gi.repository import Foo
ImportError: cannot import name Foo

vs.

>>> from gi.repository import Foo
ImportError: cannot import name Foo, introspection typelib not found


The latter example gives some extra search terms a developer not intimately familiar with GI can use to debug their problem.
Comment 4 Cole Robinson 2014-03-22 21:34:49 UTC
I like that idea. Though I tried to make it work with python 2.7 and I can't figure out how.

Raising any error from find_module() gets sanitized by python to the standard ImportError. I think we would have to lie and have find_module return successfully, only to raise the detailed import from load_module(), but I doubt that's a safe idea.
Comment 5 Simon Feltman 2014-03-22 23:26:27 UTC
Ok, that's too bad, thanks for checking it out. In any event, raising instead of returning None will raise an ImportError in both Python 2 and 3, it will just be more informative in Python 3 which works for me.
Comment 6 Simon Feltman 2014-03-22 23:34:54 UTC
Also note, we won't be able to get this in until 3.13/14. There are a few workarounds you could use to check if a typelib is available without the logged output:

Test if the results of this are not empty:

>>> gi.importer.repository.enumerate_versions('AppIndicator3')
[]

Or wrap the following with a try/except:

>>> gi.require_version('AppIndicator3', '1.0')
ValueError: Namespace Foo not available