[Qgis-developer] Qt5 and Python 3

Wed May 4 10:18:05 PDT 2016

Hi,

On Wed, May 4, 2016 at 10:09 AM, Matthias Kuhn <matthias at opengis.ch> wrote:

> 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.
>

Yes, that Qt5/PyQt4/Py2 make sense during the migration period (6 to 12
months?).

I think having Qt4/Py2, Qt5/PyQt4/Py2 and Qt5/Py3 nightlies for Mac is not
unreasonable. This will help plugin authors and core testers migrate code,
since all three could be installed on a dev Mac at the same time.

> 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.
>

That sounds great, if we can find a way to do that on a nightly basis.
Seems a bit excessive to do per Travis test build, i.e. per every commit
and PR. Well, at least for full bundling, which takes a while and might
clog the Travis queue.

Another option is to do a minimum bundled build (just qgis libs/frameworks,
Python modules and plugins). Then a user would need to have a Homebrew
dependency install to work with the artifacts. That might be the simplest.
It would be equivalent to the QGIS.app inside of the Homebrew qgis-214
prefix install, or ~58 MB compressed. Note, I do something similar at work
already, though via Jenkins builds. Would make it VERY easy/fast to
functionally test PRs on Mac.

It will require the minimum Mac OS to be 10.9 (Travis-supported OS) instead
of the current 10.7, but I was going to bump the nightlies to 10.9 anyhow,
since anything less than that is not supported via 'bottles' upstream by
Homebrew. Also, it's a totally reasonable minimum OS for a nightly.

This seems like a good plan to me:
* New Homebrew-based Mac bundling CMake routines have two bundling outputs:
minimal and full
* Travis Mac build produces a minimally bundled app as an output artifact,
which requires a Homebrew install of deps to use
* Generate fully bundled Qt4/Py2, Qt5/PyQt4/Py2 and Qt5/Py3 nightlies for
local isolated testing of plugins and core

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota

> Regards
> Matthias
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20160504/216e2687/attachment.html>