Re: PyGObject (3.4.0) - importing overrides modules from different directories

[Lukas Vacek <lucas vacek gmail com>]

Hey Simon,

Thanks for pointing me to the bug report. Yes, it is possible to load
overrides from different paths already. This goes a bit further and
allows loading overrides from different paths no matter the order of
sys.path.

Let's have a look at gst-python as it is the subject of the bug
report: if you run PYTHONPATH=path-to-gst-python python -c "import gi;
print(str(dir(gi)))" you can see gi module wasn't loaded properly.
That's because __init__.py in pygobject overrides contains other code
than just calling extend_path from pkgutil. Indeed you can use
PYTHONPATH=path-to-pygobject:path-to-gst-python and all is good.

This might seem like a trivial issue. Well, it's nothing major, but it
causes confusion - for example, the two issues in pitivi I linked in
my first email stems from this.

Cheers,
Lukas

On Fri, Oct 26, 2012 at 12:53 PM, Simon Feltman <s feltman gmail com> wrote:
> Hi Lukas,
>
> You should already be able to use overrides in different paths
> searchable by python (anything that shows up in sys.path). The trick
> is you need to use pkgutil within each of the __init__.py files within
> your custom gi/overrides folders. There are more details which may be
> a helpful in this bug report:
> https://bugzilla.gnome.org/show_bug.cgi?id=680913
>
> -Simon
>
> On Fri, Oct 26, 2012 at 4:23 AM, Lukas Vacek <lucas vacek gmail com> wrote:
>> I see the last mail didn't catch much attention. Anyway, I have come
>> up with two possible solutions to the problem.
>>
>> 1) Use imp instead of __import__
>> Just look for a file "gi/overrides/Module_name.py" in sys.path and
>> don't worry about __init__.py (overrides module can't use __init__.py
>> anyway as they clash with pygobject's overrides' init which is the
>> root cause of the whole problem), then load it with imp. It feels a
>> bit untidy but works fine. This is the attached
>> pygobject-3.4.0-overrides-load-py-files-instead-of-modules.patch.
>> Indeed this should look for other supported suffixes than .py as well.
>>
>> 2) Ask overrides module developers to symlink __init__.py
>> This solution feels cleaner and requires no changes to existing
>> pygobject code. The solution is to link __init__.py from overrides
>> modules to system pygobject overrides directory in case overrides
>> module is installed outside of pygobject tree. With autotools, this
>> can be done easily by using install-exec-hook -
>> gst-python-symlink-__init__.py-to-system-gi-overrides-on-install.patch
>> demonstrates this idea on gst-python.
>>
>> Cheers,
>> Lukas Vacek
>>
>> On Mon, Oct 22, 2012 at 1:35 PM, Lukas Vacek <lucas vacek gmail com> wrote:
>>> Hi All,
>>>
>>> I have found out it's not possible to load installed GI overrides from
>>> a different directory than where PyGObject itself is installed
>>> (/usr/lib/python2.7/dist-packages/ in my case).
>>>
>>> Ideally gi overrides modules could be installed to user site-packages
>>> directory and still would be loaded by system installation of
>>> PyGObject.
>>>
>>> The problem is that the overrides module can't install __init__.py
>>> file because it would conflict with __init__.py already installed by
>>> system PyGObject. (Or even if the file was not installed in the same
>>> location but the installed overrides module (with own __init__.py)
>>> would appear before system PyGObject in sys.path it would be loaded
>>> instead of PyGObject as gi module and break things. )
>>>
>>> However, __init__.py must be present in the gi overrides module
>>> directory in order to be recognized by __import__ call made by
>>> PyGObject when loading overrides module (module.py around line 244).
>>>
>>> This makes it complicated to use gi overrides module from a different
>>> directory. The workaround is to load _uninstalled_ gi overrides
>>> modules with PYTHONPATH which explicitly mentions PyGObject path
>>> before the path to overrides modules. For example, this is how I run
>>> pitivi: PYTHONPATH=/usr/lib/python2.7/dist-packages/:~/dev/gst-python/
>>> python bin/pitivi
>>>
>>> Pitivi bugs https://bugzilla.gnome.org/show_bug.cgi?id=686341 and
>>> https://bugzilla.gnome.org/show_bug.cgi?id=686342 seem to be related
>>> to/caused by this.
>>>
>>> To solve this pygobject might look for a ".py" file instead of a module.
>>>
>>> Thanks!
>>> Lukas Vacek
>>
>> _______________________________________________
>> python-hackers-list mailing list
>> python-hackers-list gnome org
>> https://mail.gnome.org/mailman/listinfo/python-hackers-list
>>