[Kde-bindings] A new attempt on PyKDE5 binding generation

Wed Apr 6 23:16:58 BST 2016

El dilluns, 4 d’abril de 2016, a les 18:36:16 CEST, Shaheed Haque va escriure:
> Those build dependency and packaging questions are exactly why I keep
> making remarks about needing CMake help from folks who are familiar
> with current KDE build setups (and, maybe, packaging).
> 
> So, to provide some food for thought...
> 
> 1. The way the tool works is that there is a driver.py program which
> you run something like this (simplified):
> 
> $ driver.py -I <qt5-include-root>,<kde-include-root>
> <root-of-hdrs-to-turn-into-SIP> <dest-dir>
> 
> This converts the tree of C++ header files (e.g. /usr/include/KF5)
> from argument 1 into a matching tree of SIP files in argument 2, using
> the .h files for the -I option to allow the clang parser to be able to
> understand the dependencies. Thus, the tool depends on:
> 
> - libclang3.9-dev
> - python-clang-3.9
> - Qt header files
> - KDE header files as required
> - the header files of the project you are trying to bind
> 
> 2. You then have to run the SIP compiler to generate the C++ code for
> the actual bindings. Thus this step depends on:
> 
> - the driver.py (currently in pykde5.git) plus its dependencies as above
> - PyQt5 sip files (pyqt5-dev)
> - KDE (5) sip files as required, e.g. for KF5

You lost me here, isn't this the thing we are generating on Step 1? Or you 
mean for things like if I wanted to create python bindings for libokular?

> - the SIP files of the project you are trying to bind

Ok, i think i do understand the dependencie sa bit better and the fact that a 
driver.py is needed kind of negates the possibility of every framework 
repository having it's own python bindings inside since that would make all of 
the frameworks suddenly depend on a new thing, making everything have one 
tier[1] more

I agree with you that having all the KF5 code together probably makes sense to 
at least get this bootstrapped.

But personally I would not suggest having a "kde-wide" pykde5 repo given how 
many different release schedules we have now it would be close to unmanageable 
having a single repo that has kf5+marble+krita python bindings.

So my suggestion would be renaming pykde5.git to pykf5.git, and that means 
*only* KDE Frameworks 5 bindings would go in there, any other repo that wants 
to provide python bindings (say okular, marble or krita) should do somewhere 
else, ideally their own repo so the binding and the original code are close 
together and it's easier to keep in sync when api changes.

Am I making sense?

Cheers,
  Albert

[1] https://community.kde.org/Frameworks/
Policies#Frameworks_have_a_Tier_and_a_Type

> 
> 
> In my case, I have all the external dependencies just installed using
> apt-get (i.e. header files under /usr/include, SIP files under
> /usr/share). A KDE project X developer will need to satisfy those
> dependencies somehow. I'm very hazy on how this might be done using,
> for example CMake.
> 
> Now, for KF5 itself, I propose to just create the initial set of SIP
> files in pykde5.git (BTW, I'm fine with the repo being renamed if
> deemed appropriate) just to ease the bootstrap process for everybody
> else. That said, the reason for my earlier suggestion that some
> project Xs might wish to share the repo is that whatever CMake hackery
> is required can, I guess, be then centralised to this one repo.
> 
> Again, I have no wish to impose this on anybody; all I want to do is
> get the PyKDE ecosystem going again, and then it can evolve as needed
> (CMake macros/scripts etc, packaging, whatever).
> 
> I hope that adds some colour to my earlier hints. Input, and help, welcome.
> 
> Thanks, Shaheed
> 
> On 3 April 2016 at 23:14, Albert Astals Cid <aacid at kde.org> wrote:
> > El diumenge, 3 d’abril de 2016, a les 23:04:48 CEST, Ingo Klöcker va 
escriure:
> >> On Sunday 03 April 2016 20:27:27 Shaheed Haque wrote:
> >> > What seems to be causing ripples is my suggestion that I call the
> >> > *tool* to create the SIP files something relating to PyKDE5. That made
> >> > sense to me since the tools is all about making SIP wrappers for all
> >> > of KDE(5) that wants them. Similarly, the current name of the git
> >> > repo is pykde5.git and I plan to land the KF5 bindings there.
> >> > However, as I suggested, some non-KF5 projects may find it convenient
> >> > to host their bindings there too (subject to the what little I
> >> > understand about the current CMake setup), and so that name too made
> >> > sense to me.
> >> 
> >> What do you think about simply dropping the 5 from the name and instead
> >> using the 5 as major version number? So, instead of PyKDE5 it would be
> >> PyKDE v5.x.
> > 
> > What is "pykde"?
> > 
> > My very limited understanding is:
> >  * set of bindings for python for various libraries released by the KDE
> > 
> > community.
> > 
> >  * Those libraries are all Qt5 based
> >  * Most of those libraries are part of KF5 but some are not
> > 
> > Since it's not all KF5 we can't call it pykf5.
> > 
> > pyqt5 would be misleading since would seem it's pythong bindings for qt
> > itself
> > 
> > pykdeqt5 is a bit of a mouthful but is not bad either, it's the set of py
> > bindings for kde software for qt5
> > 
> > pykde has the "brand recognition" benefit i guess since it's similar to
> > what we've been calling it, in that case though i'd prefer we don't use
> > v5.x since people would read it as "KDE5" anyway and that's a name we're
> > trying to fight off, so if pykde is chosen as a name i'd suggest going
> > with a date based versioning like YY.MM
> > 
> > Now I have a different question, given the modularization we've had, does
> > it make sense to ship all the pykde bindings in a single repo? Wouldn't
> > it make more sense for each library to ship it's binding inside? Would
> > that mean an extra dependency for each library? What dependency would
> > that be?
> > 
> > Cheers,
> > 
> >   Albert
> >> 
> >> Regards,
> >> Ingo
> > 
> > _______________________________________________
> > Kde-bindings mailing list
> > Kde-bindings at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-bindings