Installing python __init__.py file from multiple KF5 frameworks

[Elvis Stansvik]

2016-06-06 11:42 GMT+02:00 Elvis Stansvik <elvstone at gmail.com>:
>> In data giovedì 19 maggio 2016 19:00:07 CEST, Stephen Kelly ha scritto:
>>
>>> have to be changed for the namespaced module stuff?
>>
>> Sorry, you were perfectly clear. It was me who didn't get the request. ;)
>>
>>>  SOME_PYTHON_2_LOCATION/PyKF5/__init__.py
>>>  SOME_PYTHON_2_LOCATION/PyKF5/KWidgetsAddons.so
>>>  SOME_PYTHON_2_LOCATION/PyKF5/KItemModels.so
>>>  SOME_PYTHON_3_LOCATION/PyKF5/__init__.py
>>>  SOME_PYTHON_3_LOCATION/PyKF5/KWidgetsAddons.so
>>>  SOME_PYTHON_3_LOCATION/PyKF5/KItemModels.so
>>
>> Each subpackage should have its own sub-directory with an __init__.py
>> importing its contents, e.g:.
>>
>> SOME_PYTHON_3_LOCATION/PyKF5/KWidgetAddons/__init__.py
>> SOME_PYTHON_3_LOCATION/PyKF5/KWidgetsAddons/KWidgetsAddons.so
>>
>> Then, 2 different cases depending if you use Python 3 or 2.
>>
>> Python 3: the final result should look like
>>
>> SOME_PYTHON_3_LOCATION/PyKF5/
>> SOME_PYTHON_3_LOCATION/PyKF5/KWidgetAddons/__init__.py
>> SOME_PYTHON_3_LOCATION/PyKF5/KWidgetsAddons/KWidgetsAddons.so
>>
>> Python 2:
>>
>> SOME_PYTHON_2_LOCATION/PyKF5/__init__.py
>> SOME_PYTHON_2_LOCATION/PyKF5/KWidgetAddons/__init__.py
>> SOME_PYTHON_2_LOCATION/PyKF5/KWidgetsAddons/KWidgetsAddons.so
>>
>> The __init__.py should contain only
>>
>> from pkgutil import extend_path
>> __path__ = extend_path(__path__, __name__)
>>
>> This will fix it from the Python side. With regards to the __init__.py,
>
> First of all: A big thanks to Shaheed and Steve for digging down on this!
>
> Now, I understand that if you want to reap the benefits of using PEP
> 420 implicit namespace packages on Python 3, you have to use the
> nested structure described by Luca above, since namespace packages may
> not contain any modules, only subpackages.
>
> However, speaking as a Python user, consider the consequence of this
> for the import statements in Python. With the first approach (the .so
> modules directly in the KF5 package), I can do e.g:
>
> import KF5.KItemModels
>
> or say
>
> from KF5.KItemModels import KSelectionProxyModel
>
> if I want to be a little more specific. Very similar to what I do in
> PyQt (e.g. from PyQt5.QtCore import QObject).
>
> With the second approach, where each module nested in a subpackage, I
> would instead have to use the much longer and more repetitive
>
> import KF5.KItemModels.KItemModels
>
> or
>
> from KF5.KItemModels.KItemModels import KSelectionProxyModel
>
> I would therefore ask you to consider using the first approach, even
> if implicit namespace packages may seem like the "right" solution here
> (for Python 3) that is, and instead kindly ask packagers to take on
> the burden of sorting out the conflicting __init__.py files, for the
> added usability benefits.
>
> It seems that at least in Debian, the issue has already come up [1],
> although I don't know what solution is currently in place. I would
> suspect other distros have also found ways to work around this
> problem? (Zope..?)
>
> If the KF5 bindings had installed a whole bunch of .so files in each
> subpackage, it would be less of an issue I think, since then the
> subpackages would give a natural grouping. But as I understand it, it
> would essentially be a subdirectory for each framework, each
> containing a single .so ? Then there's much less motivation for the
> subpackage, from a user POV.
>
> Again, many thanks for bringing bindings to KF5. Can't wait to try them out!
>
> Best regards,
> Elvis Stansvik
>
> [1] https://wiki.debian.org/DebianPython/Namespaces

Sorry, that was apparently about an old outdated mechanism in Debian.
But it seems there are ways/practices to handle it with the newer
dh-python2 and dh-python3.

Elvis