[Qgis-developer] Qt5 and Python 3

[Matthias Kuhn]

On 04/05/16 16:49, Bas Couwenberg wrote:
> On 2016-05-04 15:08, Matthias Kuhn wrote:
>>> For the upstream QGIS packages this may be an option, for the official
>>> packages in the Debian archive it is not.
>>
>> Understandable.
>>
>> I had a look at past Debian releases, extrapolating the release cycle we
>> can expect the next release to happen in about a year.
>>
>> I don't expect a first QGIS release based on Qt5 to happen considerably
>> earlier. The first LTR based on Qt5 will certainly not happen earlier.
>>
>> Just to make sure we talk about the same order of delays. (Note: this
>> timeline has not been officially approved)
>
> Debian will switch to Qt5 with QGIS 2.16, otherwise there will be no
> QGIS in the next stable release.

I don't want to prevent you from doing that, the worst that could happen
is that you will need to set a CMake flag to void the non-existent
warranty. QGIS will happily compile and run with any Qt5 version (for now).

Just be prepared that:

 * Almost every plugin will fail (most of them with import PyQt and
python 3 related errors)
 * Even if they are migrated anything related to NULL values will still
fail because of the issue under discussion
 * This will be the case regardless of the approach to overcome this
problem (Qt 5.7 or sip.enableautoconversion(false))

> The Qt4 builds currently still work because the Qt maintainers didn't
> want to break QGIS before Qt5 support is available, but the Qt4WebKit
> removal changes have already been committed and will be included in
> the next upload. The upload may happen sooner than we'd like if
> important bugfixes need to be uploaded in the near future.

I'm happy to have Debian users as guinea pigs - but if you want to give
the best UX instead of the latest bleeding edge code with known
problems, you probably better continue shipping the current Qt4 builds
wherever possible.

I can try to see if there's another solution which only requires a sip
update and not a Qt5 update which could possibly increase the number of
possible target platforms.

On 04/05/16 17:36, Larry Shaffer wrote:
> I have started in on a complete rewrite of the CMake bundling for Mac
> (leveraging BundleUtilities) that can utilize a Homebrew backend of
> dependencies and generate a completely bundled app directly from a
> Homebrew formula. When would be a good timeframe to start releasing a
> Mac Qt5/Py3 nightly?
>
> Also, what would be the best nightly configurations for Mac to offer?
> Qt4/Py2, of course, but what other combinations make sense, i.e.
> Qt?/Py?, for testing? Or, should we focus only on offering two:
> Qt4/Py2, Qt5/Py3?

That is great news Larry.

I would stick to Qt5/Py3 (and Qt4/Py2) to keep the matrix small and
avoid plugins developed against strange combinations. In the case of OSX
a combination of Qt5/PyQt4/Py2 may also make sense because I think there
are Qt4 compatibility issues with OSX which this combination may
overcome while still offering support for the current plugin ecosystem.
But that's just a guess.

What I am really interested in is a Qt5/Python3 OSX build on travis. The
sooner we can have this the better. It could even have an on_success or
deploy step to upload master builds from the test infrastructure.

Regards
Matthias