> > (please make sure to send a copy to the mailing list when replying, your > answer is kept below for better readability). > > first of all, I'm no PySide2 dev, just a user, so I can't comment on all > your points. I'm just working on a similar project and can give you hints > on how we solved these issues there. >
Thank you very much, I also want to link my project with pyside. Thank you for notation about mail list recipients! Yes I think this is true - your bindings will not be compatible to future > or past shiboken2/PySide2 releases. Or maybe a PySide2 dev make a different > statement? > I also spoke with Cristián Maureira in telegram chat, and, as I understand him, the main goals for compatibility is using http://itanium-cxx-abi.github.io/cxx-abi/ cxx-abi. In this case, my libs will be compatable with Qt binaries. But, him also were recommend me ask my question in other community places, like mailing list ) But, there is no proven way and this is very upsetting to me ( Well, I use a specific QT version to compile and link against, but this > version is not used during runtime in the python interpreter. During > runtime, the shared libraries published with pyside2 and shiboken2 are used > from the python environment. Therefore the extra caution with importing the > PySide2 libs before importing the bindings. Note that due to different > distributions and virtual environments, it is not easily possible to > provide RPATH's for safely linking against pyside2 and shiboken2 libs. > I got example from Cristián Maureira with example of CMake project - https://code.qt.io/cgit/pyside/pyside-setup.git/tree/examples/scriptableapplication/CMakeLists.txt. There is you can see cmake functions for linking with pyside2 libraries, and this can solve our problems if we will can build with the same environment as pyside2. But, there is no ways for building in the same environment with pyside2 python package, as I understand. Therefore, I can compile with pyside2 my lib only in local, devel environment, but not a production. Probably they are not really compatible with the python manylinux > conventions (but PySide2 itself is not either, see the manlinux1 thread). > The manylinux binary distributions use old compilers and old libs to > provide binary compatibility. Same is done for QT binary distributions, but > with slightly different assumptions. manylinux2014 and Qt5.x assumptions > are sufficiently similar from my experience, though. > Ok, good suggestion! But, which compiler is actual? Clang or gcc? Which compiler flags I need to set? ) Thank you for answering! сб, 2 мая 2020 г. в 18:14, <ic...@gmx.net>: > (please make sure to send a copy to the mailing list when replying, your > answer is kept below for better readability). > > first of all, I'm no PySide2 dev, just a user, so I can't comment on all > your points. I'm just working on a similar project and can give you hints > on how we solved these issues there. > > > I need to follow by pyside2 releases and update my dependcies each time. > > Yes I think this is true - your bindings will not be compatible to future > or past shiboken2/PySide2 releases. Or maybe a PySide2 dev make a different > statement? > > > May be are there built envoronment descriptions for each OS? > > I mean, like this: > > 1. Linux 32/64 bit, clang 8.0 > > 2. Windows msvs2019 > > 3. MacOS clang 8.0 > > I think you have to stick here to the conventions used for binary python > wheel distributions. Linux binary wheels should comply to the respective > manylinux PEP's. I think for windows builds the python convention is to use > the same MSVC version which is used for building the python interpreter > itself (see here https://wiki.python.org/moin/WindowsCompilers for a > list). > > > Also, I see another approach - I will link, due compilation my, lib with > publicated Qt binaries that were used in pyside2. > > Well, I use a specific QT version to compile and link against, but this > version is not used during runtime in the python interpreter. During > runtime, the shared libraries published with pyside2 and shiboken2 are used > from the python environment. Therefore the extra caution with importing the > PySide2 libs before importing the bindings. Note that due to different > distributions and virtual environments, it is not easily possible to > provide RPATH's for safely linking against pyside2 and shiboken2 libs. > > > For example, I have linux binaries that were compiled on gcc 8.3 and Qt > 5.14.2 with the same compiler. Are they compatable with pyside2 Qt > binaries? Does users can use my signals/slots with pyside2 lib? > > Probably they are not really compatible with the python manylinux > conventions (but PySide2 itself is not either, see the manlinux1 thread). > The manylinux binary distributions use old compilers and old libs to > provide binary compatibility. Same is done for QT binary distributions, but > with slightly different assumptions. manylinux2014 and Qt5.x assumptions > are sufficiently similar from my experience, though. > > Note that your dependencies in the example are incomplete. You also use a > shiboken2_generator version and link against shiboken2 and pyside2 shared > libraries when compiling the python c extension. > > It is possible to use signals / slots in shiboken2 generated bindings of > external libraries. > > On 02.05.20 16:25, Михаил Миловидов wrote: > > It's not that bad. It's just shiboken2 and PySide2 for your package plus >> shiboken2_generator for generating the bindings. I wouldn't call this a >> nightmare. >> > The developing flow is not hard, but the problem in dependency environment. > I need to follow by pyside2 releases and update my dependcies each time. > From other side, I still not understand how to provide binary > compatibility with my lib. > > I guess you already found the docker containers provided here >> https://github.com/pypa/manylinux for generating binary python packages >> for linux. Other than that I am not aware of more resources, I think you'd >> have to integrate your library into a CI environment for your own. > > There is no problem with *developing*. > There is problem with *publicating* and *supporting*! > Of course, I can found docker container and hope that pyside2 were built > in the same, but what about Windows and MacOS? > And, as I said before, I need to follow by changes in pyside2 environment, > but at this time this is not transparency for me. > > May be are there built envoronment descriptions for each OS? > I mean, like this: > 1. Linux 32/64 bit, clang 8.0 > 2. Windows msvs2019 > 3. MacOS clang 8.0 > > Also, I see another approach - I will link, due compilation my, lib with > publicated Qt binaries that were used in pyside2. > > I just still not understand, how to compile my python package for pyside2 > compatibility. > For example, I have linux binaries that were compiled on gcc 8.3 and Qt > 5.14.2 with the same compiler. Are they compatable with pyside2 Qt > binaries? Does users can use my signals/slots with pyside2 lib? > > Thank you for attention! > > > сб, 2 мая 2020 г. в 16:38, <ic...@gmx.net>: > >> >> Thank you for answering my question! >> Looks, like a dependency nightmare ) >> >> It's not that bad. It's just shiboken2 and PySide2 for your package plus >> shiboken2_generator for generating the bindings. I wouldn't call this a >> nightmare. >> >> Are there any shared build jobs for pyside2? I mean, the jobs like >> CirclCI, TravisCI, Github Actions, etc. >> This would make creation python packages based on pyside2 much easier. >> >> I guess you already found the docker containers provided here >> https://github.com/pypa/manylinux for generating binary python packages >> for linux. Other than that I am not aware of more resources, I think you'd >> have to integrate your library into a CI environment for your own. >> >> >> >> сб, 2 мая 2020 г. в 15:18, <ic...@gmx.net>: >> >>> Hi, >>> >>> you have to use shiboken2 for creating the bindings. In the bindings xml >>> description, use the options >>> >>> <load-typesystem name="typesystem_core.xml" generate="no" /> >>> <load-typesystem name="typesystem_core_common.xml" generate="no" /> >>> >>> for being able to use QtCore (the xml files are part of PySide2). You >>> will need the shiboken2_generator package. I am using the binary package >>> provided at qt.io, even though this is not really recommended. >>> >>> From my understanding, PySide2 does not maintain binary compatibility >>> between minor versions (this is different to the C++ Qt library). This >>> means that the bindings are valid only for a specific PySide2 version (such >>> as 5.14.2.1) and this specific version should be set as a dependency in >>> your setup.py. via install_requires=["PySide2==5.14.2.1", >>> "shiboken2==5.14.2.1"]. >>> >>> If you want to provide binary packages for linux, you probably want to >>> go the manylinux2014 path (see the manylinux1 discussion a few threads >>> above). I have had troubles to get shiboken2_generator run correctly on >>> this platform, so my solution is to generate the sources on a different >>> linux system and compile them on the manylinux2014 container. >>> >>> You can use any binary compatible version of QT for developing the >>> library (e.g., 5.14.0). However, when you load your library in python, you >>> have to ensure that the correct QT library is loaded beforehand. Therefore, >>> before importing your bindings, you have to make sure that PySide2.QtCore >>> (and all other PySide2 modules) are imported before the bindings of your >>> lib. >>> >>> You may want to have a look at my work-in-progress package for >>> reference: https://github.com/ifm/nexxT, relevant portions are >>> nexxT/src/cnexxT.xml and nexxT/__init__.py (where QtCore is imported before >>> actually importing the bindings cnexxT). >>> >>> Hope this helps >>> Christoph >>> >>> On 26.04.20 22:31, Михаил Миловидов wrote: >>> >>> Hello, >>> >>> I have open source project - >>> https://marketplace.qt.io/collections/featured/products/daggy >>> I want to create python bindings for my lib such as separate python >>> package and publicate it in pip. >>> The lib - https://github.com/synacker/daggy/tree/master/src/DaggyCore) >>> - that I want to publicate based on Qt framework and has signals/slots >>> interface. >>> It means, that lib must be binary compatable with pyside2 python >>> package, for using signals and slots. >>> I think, that this lib can give boost for using Qt in python in non-gui >>> cases, because it gives solution that not exists on python: >>> >>> https://stackoverflow.com/questions/18322123/receiving-streaming-output-from-ssh-connection-in-python >>> >>> https://stackoverflow.com/questions/57066148/streaming-python-command-executed-over-ssh-in-real-time >>> >>> https://stackoverflow.com/questions/7680055/python-to-emulate-remote-tail-f >>> >>> https://stackoverflow.com/questions/18421757/live-output-from-subprocess-command >>> >>> https://stackoverflow.com/questions/50612710/read-streaming-data-over-pipe-in-python >>> >>> There are no direct ways for local or remote data streaming and >>> aggregation, but my lib will offer to do this in simple way with Qt >>> signals/slot async model. >>> Therefore, I'm very motivated in python bindings, but still not >>> understand, how to ensure binary compatibility with pyside2 python package. >>> >>> Is there any tutorials, examples or may be docker containers for >>> building Qt lib python bindings with the same envoronment, such as pyside2 >>> in pip? >>> At this time, I understand, how to compile my Qt lib python bindings >>> compatable with pyside2 only for local compilation from source, but don't >>> understand how to ensure compatibility with pyside2 from pip. >>> >>> Thank you for attention! >>> >>> _______________________________________________ >>> PySide mailing >>> listPySide@qt-project.orghttps://lists.qt-project.org/listinfo/pyside >>> >>> >>> _______________________________________________ >>> PySide mailing list >>> PySide@qt-project.org >>> https://lists.qt-project.org/listinfo/pyside >>> >> >> >
_______________________________________________ PySide mailing list PySide@qt-project.org https://lists.qt-project.org/listinfo/pyside
