Python bindings using cppyy (was: An update on Python bindings)

[Ben Cooksley]

On Sun, Jan 14, 2018 at 7:05 AM, Shaheed Haque <srhaque at theiet.org> wrote:
> Thanks to some upstream fixes, I have the cppyy-based bindings for KF5 and
> also Qt5 (see below) showing signs of life. Notes:

Hi Shaheed,

>
> The packaging has advanced to the point where I think ECM-based
> framework-by-framework bindings are a real possibility, with both Py2 and
> Py3. AFAICS, this addresses the main feedback received to date.
> With reference to the remark about tracking dependencies between frameworks,
> apologies for the delayed response as I somehow missed the email. I note
> that the dependencies currently in CMake often seem incomplete. I'll bring
> that to the community separately.
> There is one issue still open upstream
> (https://bitbucket.org/wlav/cppyy/issues/16/pragma-link-defined_in-seems-to-select).
> However, I don't consider this to be a showstopper...we might even be able
> to live with it as is.
> For me, the jury is still out on PyQt versus a new set of cppyy-based Qt
> bindings. Clearly PyQt is solid and mature, but the limitations really
> concern me (if anybody wants to know more, I'm happy to discuss, but let's
> do that in another thread please). Now, given that there are examples in the
> wild of interoperating cppyy/cling/ROOT with PyQt, I'm going to sidestep
> this question but am playing with a cppyy-based approach. At this point, all
> of Qt has basic cppyy-based bindings, and the next step is to tackle things
> like finding a way to express the object ownership/destruction rules in a
> more-or-less systematic way.
> On the P2/P3 question, I'm presently still committed to both P2 and P3. I
> *have* had a couple of minor occasions where P3-only might have been nice
> *for my code*, but if I do find an issue that tips the balance, or I find
> some serious benefit *for the bindings*, I'll drop P2. One possible such
> benefit would be if I can see a sane way to address PEP484 type hints.
>
> To get here, I had to build a subset of the tooling I previously had
> developed for the SIP-based approach. The big difference is the absence of
> any need to support customisation of the generated bindings. I am hopeful
> that in the worst case, there might be some minimal customisation (known as
> Pythonisations in cppyy parlance) such as for #4 above, but nothing like the
> scale needed for SIP.
>
> The core tooling is not specific to KF5 or KDE or Qt5, and is developed in
> upstream cppyy over on bitbucket.org. The core tooling is built around
> CMake, notably for the generation phase and the C++ library build.
>
> The PoC extends the core tooling with Pythonic packaging and installation
> using pip/wheels, also from CMake. As before I would look for help to get an
> ECM equivalent, possibly based on the same approach but perhaps including CI
> and distribution via PyPi.

Once the necessary changes and tooling have been landed into the
Frameworks (including ECM) repositories we can certainly look into any
changes that are needed on the CI system. I think the Python
development packages should already be installed though, courtesy of
the needs of other KDE software (these might be Python 3 ones though).

In regards to PyPi - are you thinking of source packages here, or binaries?

If it's sources, then it's something that would need to be handled as
part of the Frameworks release process (ideally someone other than
David would look after it, making sure each one that was being
uploaded worked). For binaries, that would be best handled by the
Binary Factory.

>
> Finally, now would be a good time for anybody else who wants to get involved
> to step up, especially as a new job limits my free time.
>
> Thanks, Shaheed

Cheers,
Ben Cooksley
KDE Sysadmin

>
> P.S. Not to stoke the the P2/P3 wars unnecessarily, but while I know that
> upstream Clang just added P3 support in the clang 5.0 release, current
> Ubuntu only packages it for 2.7.14. So I won't be moving yet...
>
> On 5 November 2017 at 13:23, Boudewijn Rempt <boud at valdyas.org> wrote:
>>
>> On Sat, 4 Nov 2017, Chris Burel wrote:
>>
>> > I think this is a remarkably short sighted statement. It assumes that
>> > people that would use these bindings have no existing Python codebase at
>> > all, and can afford to start a brand new project. The reality is much
>> > different.
>> >
>> > Let's take a specific example. I have 6 years experience writing Python
>> > for the visual effects industry. We have a 10 year old Python 2 codebase. We
>> > also use an application from Autodesk called Maya. It has been a Qt 4
>> > application with Python 2 embedded since 2012. In 2016 they jumped to qt 5
>> > and pyside2. Now Autodesk knows that companies have built large codebase
>> > around their product that requires Python 2. What would've happened if
>> > pyside2 did not support Python 2.7? They'd be stuck either forcing all their
>> > customers to move to Python 3 and risk people not wanting the new version of
>> > the software, or they'd be prevented from moving to Qt 5.
>> >
>>
>> You will have to switch to Python 3 by 2019, since that's what the VFX
>> Reference Platform says. If you haven't started on the migration yet, you're
>> very late. And the VFX Refernece Platform is basically Autodesk telling the
>> rest of the industry what to use, including their weird patchset for Qt...
>>
>> > So no, Python 2 is not dead. Not by a long shot.
>>
>> For VFX, it will be dead in 2019. See http://www.vfxplatform.com/
>>
>>
>> --
>> Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
>
>