Re: python binding's __init__.py

2016-11-16 Thread Harald Sitter
On Tue, Nov 15, 2016 at 4:04 PM, Stephen Kelly  wrote:
> Harald Sitter wrote:
>
>> Alohas
>>
>> I am currently trying to package kitemmodels' python bindings. The
>> module generator installs
>>
>> -./usr/lib/python2.7/dist-packages/PyKF5/__init__.py
>> -./usr/lib/python2.7/dist-packages/PyKF5/KItemModels.so
>>
>> This will cause a fairly shitty problem on packaging level, when a
>> second framework wants to generate bindings. Both would be installing
>> __init__.py in the same path, thus conflicting with one another, thus
>> making the packages not co-installable.
>>
>> I rather think we need a pykf5 framework which does nothing more than
>> install an empty __init__.py which will need to be installed to use
>> any bindings OR change the installation path to fully isolate the
>> directories PyKF5ItemModels/KItemModels.so.
>> Latter will make for ugly code on the python side, so I think the
>> former approach would be the best solution.
>
> Hi Harald,
>
> Thanks for working on this!
>
> Could you review the discussion in
>
>  http://comments.gmane.org/gmane.comp.kde.distributions/92
>
> ?
>
> My hope was that packagers could choose one of the KF5 packages which
> provides an __init__.py and use the file from that package, and remove it
> from any other py-kf5 packages. Is that workable?

The problem with this is that every distribution needs to do the same
thing in their ever so slightly different packaging systems.
If we apply that same solution on an upstream level we solve it for
all distributions at once. On top of that one couldn't just
arbitrarily pick a framework to install the _init_.py as then all
other python bindings would depend on this framework, even if they
have no actual link dependency, so on a package binary package level
one would probably want to separate the file into a generic pykf5
package which is a dependency of all modules. That said, IMO we should
just do that globally and introduce a pykf5 framework which does
nothing but install the __init__.py.

HS


Re: python binding's __init__.py

2016-11-15 Thread Stephen Kelly
Harald Sitter wrote:

> Alohas
> 
> I am currently trying to package kitemmodels' python bindings. The
> module generator installs
> 
> -./usr/lib/python2.7/dist-packages/PyKF5/__init__.py
> -./usr/lib/python2.7/dist-packages/PyKF5/KItemModels.so
> 
> This will cause a fairly shitty problem on packaging level, when a
> second framework wants to generate bindings. Both would be installing
> __init__.py in the same path, thus conflicting with one another, thus
> making the packages not co-installable.
> 
> I rather think we need a pykf5 framework which does nothing more than
> install an empty __init__.py which will need to be installed to use
> any bindings OR change the installation path to fully isolate the
> directories PyKF5ItemModels/KItemModels.so.
> Latter will make for ugly code on the python side, so I think the
> former approach would be the best solution.

Hi Harald,

Thanks for working on this!

Could you review the discussion in

 http://comments.gmane.org/gmane.comp.kde.distributions/92

?

My hope was that packagers could choose one of the KF5 packages which 
provides an __init__.py and use the file from that package, and remove it 
from any other py-kf5 packages. Is that workable? 

The file might get content in the future (such as version information, 
module information, documentation), but that will continue to be generated 
by ECM and will be versioned by whatever code in ECM generates the content.

Thanks,

Steve.




python binding's __init__.py

2016-11-15 Thread Harald Sitter
Alohas

I am currently trying to package kitemmodels' python bindings. The
module generator installs

-./usr/lib/python2.7/dist-packages/PyKF5/__init__.py
-./usr/lib/python2.7/dist-packages/PyKF5/KItemModels.so

This will cause a fairly shitty problem on packaging level, when a
second framework wants to generate bindings. Both would be installing
__init__.py in the same path, thus conflicting with one another, thus
making the packages not co-installable.

I rather think we need a pykf5 framework which does nothing more than
install an empty __init__.py which will need to be installed to use
any bindings OR change the installation path to fully isolate the
directories PyKF5ItemModels/KItemModels.so.
Latter will make for ugly code on the python side, so I think the
former approach would be the best solution.

HS