An update on Python bindings (Re: A new attempt on PyKDE5 binding generation)

[Shaheed Haque]

Hi Luca,

On 5 September 2017 at 23:12, Luca Beltrame <lbeltrame at kde.org> wrote:
> Il giorno Tue, 5 Sep 2017 22:12:26 +0100
> Shaheed Haque <srhaque at theiet.org> ha scritto:
>
> Hello Shaheed,
>
> first of all, thanks for continuing work on the bindings!
>
>> https://github.com/ShaheedHaque/extra-cmake-modules/tree/shaheed_master/find-modules/module_generation
>
> Even if WIP, would you mind putting it up for review in Phab? It would
> surely be useful for review.

I'm not sure the diff is especially useful as it is spiritually more
closely related to the original code in
https://cgit.kde.org/pykde5.git/log/?h=srhaque-new-sip-generator, but
then got subsetted into the ECM fork before being restored, so that by
now, Git has pretty much no clue about anything, but since you asked,
I posted it here:

https://phabricator.kde.org/D7736

>> The good news is that the approach appears to have lived up to my hope
>> in that the amount of rule code for PyKF5 needed appears to be
>
> How do you handle Framework tiers and their dependencies? It would be
> nice to track dependencies if existing: when packaging the current
> bindings, sometimes compilation would fail due to a missing sip file
> from another Framework. In an ideal world, CMake would catch that.
>
>> framework with <some ongoing owner other than me for each framework>,
>> and consolidate any needed info as Techbase documentation.
>
> Docs are important.

That's why I mentioned them :-).

> In fact, I think this approach should be merged
> only with enough docs on:
>
> - How to use it
> - How to wrap a Framework
> - How to write rules
>
> Lack of these things is what brought PyKDE4 on the state it was.

I believe there is a solid foundation for the SIP approach for both
tool maintainers and rule writers (see the various README and HOWTO
files) but IMHO, it was lack of automation rather than lack of docs
that did for PyKDE4.

(SIP does indeed lack detailed docs, but you'll only find that out
once you are as deep as I got :-), and there is plenty of coverage for
the basics (and good support too). And, FWIW, cppyy is MUCH worse!)

>> On balance, as despite the work that has gone into the SIP approach, I
>> propose to explore the cppyy option.
>
> I would want first to have a working implementation in SIP,even just
> for familiarity, unless the limitations are so great that the impair
> usage.

I have enough coverage to be able to say that the scope of what would
be needed to get functional bindings is known (to me, at least) to be
manageable. (And in any event, we *know* that SIP is enough for PyQt).

However, the whole point of my report is to say that after spending
thousands of hours of my time on SIP, I've concluded there is a need
to check if there are better alternatives from a completeness and
sustainability point of view. I would hardly suggest this course of
action if I was not VERY concerned! So, no, I don't propose to go
further with the SIP code unless cppyy falls even further short.

Thanks, Shaheed

> --
> Luca Beltrame - KDE Forums team
> GPG key ID: A29D259B