Qt 5.9?

[polarathene]

Hi, new to python ecosystem. Is there a reason that Qt 5.6.2 is the only supported version? PyQt5 and Pyside2 seem to mention support for Qt 5.9, QtQuick2 Controls(known as 2.7) seem to have a significant update in Qt 5.7.

I'd like to build these UIs with QtCreator and integrate with Python code, but for some reason conda and some pip wheels I came across are only offering Qt 5.6?

Will conda support multiple versions of Qt in future or update the current Qt version supported to 5.9(seems to also be an LTS release like 5.6)?

[mingwandroid]

In the future we'll probably adopt 5.9 (but keeping 5.6.2 for Windows when using Python 2 due to various compiler intricacies), but I do not know when anyone will have time for this. Personally I will not be able to do it for a few months.

[mingwandroid]

In the future we'll probably adopt 5.9 (but keeping 5.6.2 for Windows when using Python 2 due to various compiler intricacies), but I do not know when anyone will have time for this. Personally I will not be able to do it for a few months.

[ccordoba12]

Without @mingwandroid on board, I doubt the rest of us will have the time or energy to pursue an update to Qt, sorry.

[ccordoba12]

Without @mingwandroid on board, I doubt the rest of us will have the time or energy to pursue an update to Qt, sorry.

[mingwandroid]

I'm on board just busy.

[mingwandroid]

I'm on board just busy.

[ccordoba12]

I meant on board right now :-)

[ccordoba12]

I meant on board right now :-)

[stuarteberg]

FWIW, I will probably try building 5.9 for Mac at some point. If you don't want the Mac version to be out-of-sync with the other builds, I can keep it on my own channel.

[stuarteberg]

FWIW, I will probably try building 5.9 for Mac at some point. If you don't want the Mac version to be out-of-sync with the other builds, I can keep it on my own channel.

[polarathene]

What exactly is required to make it happen? Perhaps others can pitch in, do you need Qt built in a certain way?

[polarathene]

What exactly is required to make it happen? Perhaps others can pitch in, do you need Qt built in a certain way?

[ccordoba12]

Conda-forge and Continuum have decided to go along with the same versions for some complex packages (like this one). So until @mingwandroid and me have time to proceed with an update on the Continuum side, conda-forge is also going to remain in Qt 5.6.

[ccordoba12]

Conda-forge and Continuum have decided to go along with the same versions for some complex packages (like this one). So until @mingwandroid and me have time to proceed with an update on the Continuum side, conda-forge is also going to remain in Qt 5.6.

[polarathene]

So there isn't anything others can do to help progress the update? 5.6 was released in Mar 2016(5.6.2 in Oct 2016). There's been quite a few improvements since then.

Beyond Qt Quick Controls 2 from Qt 5.7, binary sizes can be reduced by over half, reduced startup and memory usage, some great rendering performance improvements for QML and new qt quick control types such as dialogs.

It'd be nice to see the new LTS 5.9 supported, right now QML support seems lacking with 5.6. If it's a few months off, will Continuum and Conda-forge only be providing LTS releases of Qt, and will they usually involve such a delay? I'm new to the ecosystem but was of the understanding that Conda-forge was meant to addresss the release delays with improvements to automating the process?

If there is anything that can be done to help progress this update please let me know :)

[polarathene]

So there isn't anything others can do to help progress the update? 5.6 was released in Mar 2016(5.6.2 in Oct 2016). There's been quite a few improvements since then.

Beyond Qt Quick Controls 2 from Qt 5.7, binary sizes can be reduced by over half, reduced startup and memory usage, some great rendering performance improvements for QML and new qt quick control types such as dialogs.

It'd be nice to see the new LTS 5.9 supported, right now QML support seems lacking with 5.6. If it's a few months off, will Continuum and Conda-forge only be providing LTS releases of Qt, and will they usually involve such a delay? I'm new to the ecosystem but was of the understanding that Conda-forge was meant to addresss the release delays with improvements to automating the process?

If there is anything that can be done to help progress this update please let me know :)

[gillins]

@polarathene It's important to remember that Visual Studio 2008 (needed for Python 2.7 on Windows) won't compile 5.9. In fact it barely manages to compile 5.6.

When we move to 5.9, Python 2.7 on Windows will have to remain with 5.6 leading to further fragmentation and confusion on the part of users and I suspect this is another reason why no one is in a hurry to do anything here...

[gillins]

@polarathene It's important to remember that Visual Studio 2008 (needed for Python 2.7 on Windows) won't compile 5.9. In fact it barely manages to compile 5.6.

When we move to 5.9, Python 2.7 on Windows will have to remain with 5.6 leading to further fragmentation and confusion on the part of users and I suspect this is another reason why no one is in a hurry to do anything here...

[polarathene]

How long will that be a good argument for? Python 2 is set for EOL by 2020. I don't know about other dependencies that will fail to compile on VS2008 but this is likely to become more of a common trend in future right? Qt will continue to be developed and unlikely to support compiling via VS2008 I assume...

I'm not sure how this will be addressed due to being new to how Python developers manage things like this(conda seems to be the advised way and meant to solve the issues pip had with dependencies like these afaik). Can you not default to Qt 5.6 with some way to support newer versions? I believe when I was installing TensorFlow a month ago, it didn't support Python 3.6 at the time, so you needed to use an earlier version of Python which is fine. Likewise for Qt, I made a conda environment and the command mentioned the desired python and Qt versions, when trying 59 instead of 56 for Qt I got an error to let me know it wasn't available(that's fine). Having tools like conda/pip, npm, cargo, etc to let me pull in what I want and sort out compatible versions or warn/error me about issues like that is their purpose? Rust's cargo for example let's you use flags for features or versions of dependencies that would otherwise not be available by default for broader support.

Point is you're going to run into that fragmentation issue in future, while hindering those using Python 3 in the meantime. So is this a case where conda doesn't currently support handling? Using Qt with Python has already been confusing to look into already(PyQt and PySide Qt4/5 variants, Qt.py and QtPy abstractions over the two main Qt packages but both only seem to support QtWidgets, PySide2 seeming to be a pain to get setup on Windows, and a few other related issues).

How many devs are using Python 2.7 for Qt projects with a need for > Qt 5.6 support? Are they likely to be confused about Qt 5.9 not being available and only being available on Python 3?(where you have similar cases already with language features) Is a new project using Qt likely to be in Python 3 and wanting to take advantage of the improvements after Qt 5.6? Quite likely I'd assume, unless it's by a team that's been using Python 2.7 and Qt 5.6.2 extensively already for domains like enterprise or governments where they're far less likely to have a need to for anything newer(are these kinds of developers going to be confused about Python 2.7 lacking newer versions of Qt?).

conda-forge from what I understand is a source conda can use for getting packages where whatever conda is offering isn't enough for the users needs? If the teams for both are reluctant to support a new version of Qt for fragmentation reasons and not so much time(where the community could assist), what options do I have if I'd like to use Qt 5.9 this year? Can I build Qt 5.9 for Windows and Linux and anything else required to make my own conda setup use it like conda-forge?(and then switch to conda/conda-forge when 5.9 is officially supported) Or am I better using the unofficial pip wheels I've come across?(PySide2 with Qt5.9, haven't looked for PyQt5 with Qt 5.9 yet)

[polarathene]

How long will that be a good argument for? Python 2 is set for EOL by 2020. I don't know about other dependencies that will fail to compile on VS2008 but this is likely to become more of a common trend in future right? Qt will continue to be developed and unlikely to support compiling via VS2008 I assume...

I'm not sure how this will be addressed due to being new to how Python developers manage things like this(conda seems to be the advised way and meant to solve the issues pip had with dependencies like these afaik). Can you not default to Qt 5.6 with some way to support newer versions? I believe when I was installing TensorFlow a month ago, it didn't support Python 3.6 at the time, so you needed to use an earlier version of Python which is fine. Likewise for Qt, I made a conda environment and the command mentioned the desired python and Qt versions, when trying 59 instead of 56 for Qt I got an error to let me know it wasn't available(that's fine). Having tools like conda/pip, npm, cargo, etc to let me pull in what I want and sort out compatible versions or warn/error me about issues like that is their purpose? Rust's cargo for example let's you use flags for features or versions of dependencies that would otherwise not be available by default for broader support.

Point is you're going to run into that fragmentation issue in future, while hindering those using Python 3 in the meantime. So is this a case where conda doesn't currently support handling? Using Qt with Python has already been confusing to look into already(PyQt and PySide Qt4/5 variants, Qt.py and QtPy abstractions over the two main Qt packages but both only seem to support QtWidgets, PySide2 seeming to be a pain to get setup on Windows, and a few other related issues).

How many devs are using Python 2.7 for Qt projects with a need for > Qt 5.6 support? Are they likely to be confused about Qt 5.9 not being available and only being available on Python 3?(where you have similar cases already with language features) Is a new project using Qt likely to be in Python 3 and wanting to take advantage of the improvements after Qt 5.6? Quite likely I'd assume, unless it's by a team that's been using Python 2.7 and Qt 5.6.2 extensively already for domains like enterprise or governments where they're far less likely to have a need to for anything newer(are these kinds of developers going to be confused about Python 2.7 lacking newer versions of Qt?).

conda-forge from what I understand is a source conda can use for getting packages where whatever conda is offering isn't enough for the users needs? If the teams for both are reluctant to support a new version of Qt for fragmentation reasons and not so much time(where the community could assist), what options do I have if I'd like to use Qt 5.9 this year? Can I build Qt 5.9 for Windows and Linux and anything else required to make my own conda setup use it like conda-forge?(and then switch to conda/conda-forge when 5.9 is officially supported) Or am I better using the unofficial pip wheels I've come across?(PySide2 with Qt5.9, haven't looked for PyQt5 with Qt 5.9 yet)

[gillins]

How long will that be a good argument for?

I didn't say it was a good argument - just a fact of life 😄 I 100% get what you are saying about wanting later versions etc and new software not going to be available for Python 2.7.

IMHO the Conda way forward would be to create your own channel and upload 5.9 packages there and test. Then once these are working send your recipes to @mingwandroid and @ccordoba12 and that will assist them in updating defaults and conda-forge.

[gillins]

How long will that be a good argument for?

I didn't say it was a good argument - just a fact of life 😄 I 100% get what you are saying about wanting later versions etc and new software not going to be available for Python 2.7.

IMHO the Conda way forward would be to create your own channel and upload 5.9 packages there and test. Then once these are working send your recipes to @mingwandroid and @ccordoba12 and that will assist them in updating defaults and conda-forge.

[ccordoba12]

I agree with @gillins, if you want to help, please start compiling Qt 5.9 and send us a working recipe.

To compile 5.6 we invested ~300 hours, along with @msarahan. Since we know it's a big effort and there's a big change in progress in how we build packages at Continuum, I'm afraid we'll have to postpone this (most probably) to next year.

---

Or am I better using the unofficial pip wheels I've come across? (PySide2 with Qt5.9, haven't looked for PyQt5 with Qt 5.9 yet)

That's your best option. But only the pyqt5 wheels are completely self-contained and available for all OSes. The PySide2 ones require an external Qt installation, and so far are only available for Linux.

[ccordoba12]

I agree with @gillins, if you want to help, please start compiling Qt 5.9 and send us a working recipe.

To compile 5.6 we invested ~300 hours, along with @msarahan. Since we know it's a big effort and there's a big change in progress in how we build packages at Continuum, I'm afraid we'll have to postpone this (most probably) to next year.

---

Or am I better using the unofficial pip wheels I've come across? (PySide2 with Qt5.9, haven't looked for PyQt5 with Qt 5.9 yet)

That's your best option. But only the pyqt5 wheels are completely self-contained and available for all OSes. The PySide2 ones require an external Qt installation, and so far are only available for Linux.

[polarathene]

To compile 5.6 we invested ~300 hours

Any takeaways from that experience that might be helpful for someone new to all this?
5.6 was the first Qt version supported I take it?
Do you anticipate it taking that long roughly again for 5.9? If so what was some of the parts of the process that took the longest beyond compile time?(which I assume isn't much of that time?)

and there's a big change in progress in how we build packages at Continuum

So even if I did go through the effort, the PR is less likely to be accepted to help out the community due to future changes? I'd be happy to help, but if the effort to do so is as large as you anticipate and that contribution would be short-lived due to a change in processes, I think I'll sit out on that.

I'm afraid we'll have to postpone this (most probably) to next year.

Rough estimate that it might be sorted next year by? Q2, H2 or later?

The PySide2 ones require an external Qt installation, and so far are only available for Linux.

That'd explain why it was a breeze to get sorted on Arch Linux, there was an AUR package for PySide2-git, took a few hours to build and just worked. The Windows wheel I used which had Qt 5.9 I need to look into a bit as it's causing problems.

[polarathene]

To compile 5.6 we invested ~300 hours

Any takeaways from that experience that might be helpful for someone new to all this?
5.6 was the first Qt version supported I take it?
Do you anticipate it taking that long roughly again for 5.9? If so what was some of the parts of the process that took the longest beyond compile time?(which I assume isn't much of that time?)

and there's a big change in progress in how we build packages at Continuum

So even if I did go through the effort, the PR is less likely to be accepted to help out the community due to future changes? I'd be happy to help, but if the effort to do so is as large as you anticipate and that contribution would be short-lived due to a change in processes, I think I'll sit out on that.

I'm afraid we'll have to postpone this (most probably) to next year.

Rough estimate that it might be sorted next year by? Q2, H2 or later?

The PySide2 ones require an external Qt installation, and so far are only available for Linux.

That'd explain why it was a breeze to get sorted on Arch Linux, there was an AUR package for PySide2-git, took a few hours to build and just worked. The Windows wheel I used which had Qt 5.9 I need to look into a bit as it's causing problems.

[ccordoba12]

Any takeaways from that experience that might be helpful for someone new to all this?

Our experience is basically reflected in the recipe present in this repo.

5.6 was the first Qt version supported I take it?

We started with 5.5 internally.

Do you anticipate it taking that long roughly again for 5.9?

No, I don't think so. The most problematic Qt piece should be WebEngine.

If so what was some of the parts of the process that took the longest beyond compile time?(which I assume isn't much of that time?)

Tweaking qt.conf to support conda envs, but that's settled now.

So even if I did go through the effort, the PR is less likely to be accepted to help out the community due to future changes?

No. The changes I referred to are about our internal infrastructure. Conda recipes are not going to be affected by them.

Rough estimate that it might be sorted next year by? Q2, H2 or later?

H1

[ccordoba12]

Any takeaways from that experience that might be helpful for someone new to all this?

Our experience is basically reflected in the recipe present in this repo.

5.6 was the first Qt version supported I take it?

We started with 5.5 internally.

Do you anticipate it taking that long roughly again for 5.9?

No, I don't think so. The most problematic Qt piece should be WebEngine.

If so what was some of the parts of the process that took the longest beyond compile time?(which I assume isn't much of that time?)

Tweaking qt.conf to support conda envs, but that's settled now.

So even if I did go through the effort, the PR is less likely to be accepted to help out the community due to future changes?

No. The changes I referred to are about our internal infrastructure. Conda recipes are not going to be affected by them.

Rough estimate that it might be sorted next year by? Q2, H2 or later?

H1

[justlurking]

@stuarteberg Were you able to get qt 5.9 built for mac? I tried your username but wasn't able to find your conda channel with a brief search.

I'm running into problems with 5.6.2 which (supposedly) have been fixed in more recent versions. Would be great to get qt 5.9 before the estimated 1H of next year (which, as we all know, is probably optimistic the way fires pop up and resource availability changes).

[justlurking]

@stuarteberg Were you able to get qt 5.9 built for mac? I tried your username but wasn't able to find your conda channel with a brief search.

I'm running into problems with 5.6.2 which (supposedly) have been fixed in more recent versions. Would be great to get qt 5.9 before the estimated 1H of next year (which, as we all know, is probably optimistic the way fires pop up and resource availability changes).

[stuarteberg]

@justlurking No, I haven't really given it a proper effort yet. I did briefly check to see if our patches for 5.6 just happen to cleanly apply to the 5.9 code base (by some miracle), but they do not.

If you're interested in taking a crack a this yourself, I suppose the first step would be to evaluate the patches that are applied on Mac (0005-0010) and figure out which ones are still needed in Qt 5.9.

After that, it's a matter of generating new patch files where needed, and then attempting to build the recipe on a mac with the 10.9 SDK installed (via the XcodeLegacy tool).

The build itself will take several hours, largely due to the fact that it builds all of Chromium.

[stuarteberg]

@justlurking No, I haven't really given it a proper effort yet. I did briefly check to see if our patches for 5.6 just happen to cleanly apply to the 5.9 code base (by some miracle), but they do not.

If you're interested in taking a crack a this yourself, I suppose the first step would be to evaluate the patches that are applied on Mac (0005-0010) and figure out which ones are still needed in Qt 5.9.

After that, it's a matter of generating new patch files where needed, and then attempting to build the recipe on a mac with the 10.9 SDK installed (via the XcodeLegacy tool).

The build itself will take several hours, largely due to the fact that it builds all of Chromium.

[justlurking]

@stuarteberg Thank you for the update and for laying out what needs to be done. I'm afraid that's not something I can take on right now, but perhaps someone else will pick up the baton.

[justlurking]

@stuarteberg Thank you for the update and for laying out what needs to be done. I'm afraid that's not something I can take on right now, but perhaps someone else will pick up the baton.

[EmanueleCannizzaro]

@ccordoba12 It seems that the version 5.6 has no wayland module and therefore anaconda-navigator won't start in kde wayland.

I get the following message:

anaconda-navigator
This application failed to start because it could not find or load the Qt platform plugin "wayland"
in "".

Available platform plugins are: minimal, offscreen, xcb.

Reinstalling the application may fix this problem.
Aborted

Thank you
Emanuele

[EmanueleCannizzaro]

@ccordoba12 It seems that the version 5.6 has no wayland module and therefore anaconda-navigator won't start in kde wayland.

I get the following message:

anaconda-navigator
This application failed to start because it could not find or load the Qt platform plugin "wayland"
in "".

Available platform plugins are: minimal, offscreen, xcb.

Reinstalling the application may fix this problem.
Aborted

Thank you
Emanuele

[mingwandroid]

You need to install xwayland

[mingwandroid]

You need to install xwayland

[stuarteberg]

Out of curiosity: Once this recipe is updated for Qt 5.9, will we also attempt to include the WebEngine component in the Linux build? (Currently, it is only included in the mac build.)

cc @tingzhao @stephenplaza

[stuarteberg]

Out of curiosity: Once this recipe is updated for Qt 5.9, will we also attempt to include the WebEngine component in the Linux build? (Currently, it is only included in the mac build.)

cc @tingzhao @stephenplaza

[mingwandroid]

I'm including webengine on all 3 OSes.

Some test packages are available on anaconda.org/rdonnelly/qt

[mingwandroid]

I'm including webengine on all 3 OSes.

Some test packages are available on anaconda.org/rdonnelly/qt

[stuarteberg]

I'm including webengine on all 3 OSes.

Awesome, thanks Ray!

@tingzhao, @hubbardp -- When you get a chance, maybe you can try Ray's test packages:

conda install -c rdonnelly qt=5.9

[stuarteberg]

I'm including webengine on all 3 OSes.

Awesome, thanks Ray!

@tingzhao, @hubbardp -- When you get a chance, maybe you can try Ray's test packages:

conda install -c rdonnelly qt=5.9

[mingwandroid]

Not sure how compatible these builds are with conda-forge, though achieving that is an explicit goal.

In the meantime you may need to use the defaults channel.

Beyond compiling Qbs and QtCreator on Linux and macOS I have literally not tested these yet.

[mingwandroid]

Not sure how compatible these builds are with conda-forge, though achieving that is an explicit goal.

In the meantime you may need to use the defaults channel.

Beyond compiling Qbs and QtCreator on Linux and macOS I have literally not tested these yet.