qtpy: Add a deprecation warning for unsupported `Qt` versions and bindings (at least `Qt4`: `PyQt4` and `PySide`)

Instead, let’s open a new issue and fix it with a new PR.

That also makes the most sense to me 👍 . I can open a new issue.

I think we should leave this message for QtPy 2.0

I’m not sure about that, but we can discuss that in the new issue. I’ll try to compile the relevant bits from each of us there to get things started.

Yeah, thanks are going okay for now at the moment in that department, thanks 👍

Thanks @CAM-Gerlach , don’t worry and hope everything is going ok

regarding the message for Qt 5 <5.9

I think we should leave this message for QtPy 2.0

Should we reopen this issue and close it with the merge of that new PR?

I’m not in favor of that. Instead, let’s open a new issue and fix it with a new PR. This issue was about the Qt4 message.

One thing, though—this and #281 / #280 were all milestoned on 1.11.3, but #281 also bumped the QtPy 1.x version to 1.12. Was the latter intentional and we should rename the milestone, or is the former still correct? Thanks.

@CAM-Gerlach see https://github.com/spyder-ide/qtpy/pull/281#issuecomment-972950279

Oh, so we already warn on Qt <5.6 and/or <5.9?

No, we don’t. Perhaps we should warn about Qt < 5.9 because the oldest version we can test.

Ah yes that makes sense, will reword this issue then 👍

Here we are checking the deprecation warning message for Qt4 (which should go only to the 1.x branch) so not related with #233 .

Sorry if I was unclear. I assumed this issue was motivated by the fact that Qt4 binding support is removed in QtPy 2.0, untested and deprecated in QtPy 1.x, and EoL upstream. Since all three of these reasons are equally true for Qt5 <5.9/5.12 (the specifics of which are being discussed in #233 ), I thought it might make sense to consider warning for that here as well (considering I’d think we’d want to decide on that before you make a final QtPy 1.x release with this change).

Sure, it should be simple to do, just a if block at the end of __init__() issuing a warning as the above, minus the user portions. Here’s what I propose:

LEGACY_APIS = PYQT4_API + PYSIDE_API
if API in LEGACY_APIS or initial_api in LEGACY_APIS:
    warnings.warn(
        "A deprecated Qt4-based binding (PyQt4/PySide) was installed, "
        "imported or set via the QT_API environment variable. "
        "To ensure their applications are still supported in QtPy 2.0, "
        "developers should ensure they don't depend upon, import or "
        "set the QT_API env var to 'pyqt', 'pyqt4' or 'pyside'.",
        DeprecationWarning,
        )

Ideally LEGACY_APIS would be a frozenset rather than a list, but that matches the type of the other such constants.

I think that sounds good, but lets wait to see what others think.

We might also want to consider a warning if a version of PyQt (e…g. < 5.9 or at least <5.6), and/or PySide2 (e.g. < 5.12) is used that would similarly be unsupported in QtPy 2.0.0.

Thats true, yes, I would say that the acceptable minimum for PyQt could be >=5.9 (since is the lates version in the anaconda channel) but since there are some issues regarding scoped enums with that version for Python 3.6 and 3.7 probably at the end the minimum will be something like >=5.12 as with PySide2. However we need to further discuss this too

Thanks @CAM-Gerlach for checking on this and giving some suggestions! From my side I would say:

Point 1 - DeprecationWarning vs UserWarning: I would say DeprecationWarning since when thinking about this I was mostly thinking in devs that use QtPy for their applications.

Point 2 - Tha validation: I will say both since we should cover all usages of Qt4 that will not be supported (either automatic detection or user defined variables).

Point 3 - The message: A generic warning explaining that Qt4 will not be supported anymore (i.e PyQt4 and PySide) should be enough I think

What do you think @ccordoba12 ? Also maybe @andfoy or @steff456 have some ideas regarding approaches to this?

And also @CAM-Gerlach would you like to work on this?