kdev-python: plans to add support for PyQt6 & PySide2/6 ?

[Björn Strömberg]

Hello Francis,

thanks for the info on SIP, then i guess that is the reason for Qt going
with shiboken and not reuse SIP due to PyQt licensing its GPL, thats the
reason for PySide from start to be lgpl licensed.


I've actually tried to manually generate the output on a running system
just to get rid of the warnings of missing data, pushed its output as a
quick merge req for release/23.08

so kdev-python actually seems to have extracted the data required from the
pyi files generated via python..

someone that actually have knowledge of how these files should look would
be appriciated if you look at them and see what is missing or so cause I
have no clue what to expect from kdevelop in python context.

i do not think they work as they should since the dropdown for autocomplete
does trigger red error invalid syntax on a singe dot on a object member,
but if i start writing a 's' after the dot it actually works..

my interest is mainly getting PySide6 and generate a PyKSide6 with
shiboken6 to be able to prototype in python due to lgpl licensing,
on a longer timeframe I'm good with working to upstream some of the work,
I find PySide/PyKfSide6 a suitable solution for prototyping for my own
usage due to the fact they are lgpl licensed, and PyQt is gpl..

i will try to help get some progress into kdev-python, but currently I'm
pretty strapped for time, so it will mostly be the parts that get me
forward that i can work on full time.

Regards
Björn

On Wed, Jan 3, 2024 at 6:10 PM <mail at flherne.uk> wrote:

> On 2024-01-03 06:57, Björn Strömberg wrote:
> > On Tue, Jan 2, 2024 at 10:11 PM Sven Brauch <mail at svenbrauch.de>
> > wrote:
> >
> >> Hi,
> >>
> >> a word of caution, I haven't looked at these bindings for about ten
> >> years, which is also approximately how outdated they are.
> >
> > yea i know the bindings are out of date, its visible by the datestamps
> > on the folders,
> > that was the reason for the question of autogenerating them on build
> > instead,
> > might be a bit more work upfront but should payoff in the long run..
> >
> > one thing with open source is the fact that sometimes you just have to
> > get into it and try to help out when stuff you need seems to be stuck
> > in the mud, or aleast stuck in the mud from your P.O.V..
> >
> > I will try to see if i can help out some, mainly cause it seems like
> > PySide2/6 will be a solution to help me be more productive (C++/Qt dev
> > with to much work and to little time),
> > now i need the tooling, and that part is currently based on getting a
> > working Alpine Linux - KDE Environment (preferably before 24.02
> > release),
> > to get that i need i need a working KDevelop with Python support..
> >
> > by now our paths have crossed, now my process is to get to know where
> > kdev-python is heading and if i need to hardfork or if we can get
> > along and it will be better for all..
> >
> > i would prefer not to have to maintain a separate fork, but that
> > requires to work with current maintenence 'crew' and so far you seem
> > reasonable so i think it will work.
> >
> > this is the reason for this mailing list 'thread', to find out of this
> > project actually still is viable or if a fork is the only way forward.
> >
> > i got about two months (deadlines for 24.02) where I'll use some free
> > time for this project to advance my 'Alpine Linux' context where i
> > will have to maintain custom application repositories on top of their
> > main for private reasons.
> >
> >> On 02.01.24 09:33, Björn Strömberg wrote:
> >>> the process as i see it (for KF5/KF6 in case they do not have
> >> python
> >>> wrappers like pyside) we got the qt tools to generate pyside2/6
> >>>
> >>> * shiboken2 https://doc.qt.io/qtforpython-5/shiboken2/index.html
> >>> <https://doc.qt.io/qtforpython-5/shiboken2/index.html>
> >>> * shiboken6 https://doc.qt.io/qtforpython-6/shiboken6/index.html
> >>> <https://doc.qt.io/qtforpython-6/shiboken6/index.html>
> >>>
> >>> to generate the python interfaces, then what we need is something
> >> to
> >>> read those interfaces to create the manuals,
> >>
> >> I'm not sure we're talking about the right thing here. We don't need
> >> to
> >> generate the bindings, other people have already done that, we only
> >> need
> >> to generate files containing the relevant definitions and docs in
> >> the
> >> right format for kdev-python to understand. This format is the
> >> "header-like" files you've found.
> >
> > the KF5 / KF6 binding question is for the fact i can't seem to find
> > any upstream of that, it does not seem to be a PyKF5 that KDE supplies
> > as official..
> > https://github.com/blackPantherOS/frameworks-bindings/tree/master &
> > https://github.com/steveire/frameworks-bindings this testings are
> > ~8years old now..
> >
> > and duckduckgo cant seem to find anything useful on the subject, this
> > is the only thing i get on google that is somewhat close..
> >
> https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/37
> >
> > if we're serious about having kdev-python and PyQt6/PySide6 support,
> > then there should actually be a python binding support for 'our' KDE
> > Frameworks that build on top of them, but where are they?
> > does every kf-module build its own bindings?
> >
> > the reason there is no KF5 bindings that are seem supported is the
> > reason I've keept away from Python + Qt, dont see the reason to
> > reinvent the wheel if someone actually have done the binding work for
> > KF5/6..
> >
> >> They used to be generated from the SIP description files for PyQt,
> >> and
> >> from a quick glance it looks like that could still work in
> >> principle.
> >> The scripts to do that are in the "documentation_src" folder, but
> >> will
> >> certainly need some changes (apparently the SIP command line
> >> interface
> >> has changed and the files have also moved, but maybe there are more
> >> rocks in the way).
> >
> > no clue what SIP is? the closes i get from a search engine: Session
> > Initiation Protocol (SIP)
> >
> > but that seems to be the wrong context.. there is no actual
> > description files in documentation_src folder, i can find a notes.txt
> > that seems incomplete..
> > so i guess its something somewhere in the documentation process like
> > doxygen 'IR' output somewhere, but i have not digged deep in that area
> > yet.
> >
> >> Feel free to have a look if you are interested, or alternatively in
> >> the
> >> next months I'll need to do a bit of maintenance anyways to add
> >> support
> >> for Python 3.12, then I can also see if I can update those scripts
> >> to
> >> support PyQt6 and current SIP. No promises though ;)
> >>
> >> Greetings,
> >> Sven
> >
> > I'll dig into the problem and see if i can untangle the process of how
> > to actually do the full process, if you can fill in more on the
> > process and where to look it would be appriciated..
> >
> > when i get the full process of how its done, it can be automated, then
> > we need to decide how to automate it and the way there...
> >
> > Greetings
> > Björn
>
> Hi Björn,
>
> SIP in this context is a tool used to generate Python bindings for C++
> code, and in particular to produce PyQt:
> https://www.riverbankcomputing.com/software/sip/
> https://en.wikipedia.org/wiki/SIP_(software)
>
> pyside's Shiboken that you've linked appears to be roughly equivalent
> although I'm not familiar with it.
>
> When the documentation stubs were last touched, Qt support/control of
> pyside didn't exist. PyQt was far more mature and the obvious choice of
> bindings. It's been years since I used Qt from Python code, it looks
> like pyside/"Qt for Python" has come on a lot in the meantime.
>
> The KF5 Python bindings were generated for each library using SIP via
> some KDE-wide CMake tooling, but regrettably seem to be dead now:
> https://mail.kde.org/pipermail/distributions/2022-February/001148.html
>
> Projects with Python bindings generated by SIP come with `*.sip` files
> that describe their API,
> for example under sip/ in the PyQt source
> https://pypi.org/project/PyQt6/#files
>
> These were read and converted by documentation_src/pyqt/generate.sh
> (using the python scripts in the same dir) to produce the current
> outdated PyQt stubs.
> Looking at the old scripts might be helpful but they're *long* dead and
> won't work. You're probably better off starting from scratch whatever
> you do.
>
> At the time these stub files were generated there was no upstream
> solution, so they're a kdev-python-specific hack.
>
> The long-term solution would be to improve kdev-python's support for
> PEP-484 type hinting and have it parse `*.pyi` stub files which are the
> newer, upstream-supported solution with a lot of tooling behind them.
>
> PySide, PyQt and numpy all provide `*.pyi` stub files so kdev-python's
> own format would be entirely obsolete if we supported these properly.
> There would be no need to generate, ship or parse our own stubs and they
> could be removed entirely.
>
> It would also significantly improve kdev-python's support for other
> libraries using standard `*.pyi` files for which kdev-python has never
> had stub files.
>
> Unfortunately support for PEP-484 (and successors) typing is a major
> project that would require a lot of digging into KDevelop and
> kdev-python internals. I believe it's possible, and once intended to
> implement it but have been occupied with other things outside KDE.
>
> I'm happy to discuss stuff by email (as I'm sure Sven is) or on IRC
> where I'm FLHerne.
>
> It's good to see someone new taking an interest in kdev-python!
>
> Yours,
> -Francis Herne
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20240103/e41c59fa/attachment-0001.htm>