[Qgis-developer] [Qgis-psc] Clarification of outcome of PSC meeting 16/1

[Nathan Woodrow]

We have a import hook in place so it would be possible to have just import
PyQt and handle which version is imported on our side however this is a bit
magic and I'm not sure many people would like it. Stuff like this also
breaks tooling because there is no PyQt module so most auto complete will
not work. (I have tried this trick before to strip Qgs from the front of
all classes on the fly)

I'm not sure there is a really good solution to this without breaking
something or hacks. IMO using PyQt4 with Qt5 will just confuse people and
like you said most platforms might drop that.   Pro tip: This is a good
reason to never name your modules with the version at the end.

Nathan

On Sun, 18 Jan 2015 5:47 am Matthias Kuhn <matthias at opengis.ch> wrote:

> Hi all,
>
> Sorry for the long mail but I think it is an important topic.
>
> Increasing the major version number is a rather big step and should be
> considered carefully. So before going into too many technical details
> (no worries, you find them below) I think it is important to have a
> clear idea why we would want that and what we expect from this move. In
> order to avoid another troublesome major version change (QGIS 4) for as
> long as possible.
> Qt 5 and Python 3 are IMO mandatory changes when QGIS 3 comes but they
> should not be the cause for it but rather dependencies of it.
>
> I thought that it would be a good idea to use the QEP process to handle
> this. We could create a label QGIS3 there which we could apply to QEPs
> that will require QGIS3. And another QEP specifically for QGIS 3, that
> lists other things to do (cleanup of deprecated API, Qt 5, Python 3...).
>
> Some ideas what could be labelled with QGIS3:
>
>  * Composer -> Layout
>  * Database aware datasources (Make QGIS aware of
> datasources(providers/tables) on the same database. That would allow to
> better handle database dependent properties like foreign keys (which
> involve multiple tables).
>  * Abstraction of the .qgs file structure. Now it depends on XML. A new
> project format including portable layers (memory saver) may use
> something different. Or stick to XML.
>  * Geometry redesign (It's a rather big rework, I guess there will be
> some implications on the API leading to different behavior. I don't know
> it in detail and the roadmap)
>  * [Your idea goes here]
>
> And now to the technical notes:
> I think that both Qt 5 and Python 3 are ready to be used. They are
> available for almost any platform and are can be considered stable. If
> we switch the major version number in QGIS to 3, they should be made a
> highly recommended dependency and developers should treat them as the
> main target.
>
> At least for Qt5 I can say that it is compatible to Qt4 to a very high
> degree. I think also for python it is possible to write code that works
> with python 2.7 and 3.x (The pandas module which is quite complex is
> compatible with both). That means, it should be possible to make plugins
> work independent of these versions.
>
> There is one thing however that causes me some headaches which is PyQt5.
> This must not be set equal with Qt5. It is possible to combine Qt5 with
> PyQt4 (Read that again!) [1]. With this combination all the above
> compatibility notes (should) apply.
> Upgrading to PyQt5 however comes with some caveats. PyQt5 removes all
> the deprecated things from Qt. That may affect some plugins. Even worse,
> it forces python plugins to change their imports. Instead of "import
> PyQt4" one will have to write "import PyQt5". Basically rendering all
> plugins incompatible.
>
> So we could consider to switch to Qt5 and keep PyQt4 and have an easy
> transition. However, I hardly doubt that every platform will offer this
> combination. Most distributions will probably do the obvious and bundle
> PyQt4 linked against Qt4 and PyQt5 linked against Qt5.
>
> This leaves us with the options:
>
>  1. Include PyQt4 in our sources (you may deduce my stance to this from
> the discussion here [2])
>  2. Switch to PyQt5 and force all plugins to update
>
> Version 2 would render all plugins subsequently incompatible with QGIS 2
> what would probably disappoint many. So I thought that python may be
> flexible enough  to offer aliases for modules (is it, python experts?).
> So would it be possible to alias both - PyQt4 and PyQt5 - with PyQt?
> That way plugins could be updated with an easy search-and-replace to
> just import PyQt (and check for PyQt.version if required) and still have
> them work with QGIS 2 and QGIS 3.
>
> Regards,
> Matthias
>
> [1] http://pyqt.sourceforge.net/Docs/PyQt5/pyqt4_differences.html
> [2] https://github.com/qgis/QGIS/pull/1726
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150117/9bd2ab11/attachment.html>