Qt5.py

[mottosso]

I put together a preliminary successor of Qt.py for PySide2 and PyQt5 only, an alternative being "upgrading" Qt.py itself, dropping support for Qt 4.

• Qt5.py
• Initial discussion

Benefits of a separate project

1. Co-existence. Use Qt.py and Qt5.py at the same time, in the same Python session
2. Clarity; users won't wonder whether their Qt.py supports QML or other Qt 5-only features
3. What else?

Benefits of an "upgrade"

1. Maintain userbase
2. Familiarity
3. What else?

[fredrikaverpil]

Another benefit is you can install Qt.py and Qt5.py in the same virtual environment and actually even use them in different parts of your app, depending on which parts may be running inside of a Qt4 host application or not.

[mottosso]

That's actually what I had in mind for "co-existence". I've updated the description of it to make it more clear, sorry about that!

[fredrikaverpil]

You've called this project Qt5.py which implies there could potentially be a Qt6.py down the road... is this your intention, or would it make more sense to remove the major version number from the project and instead use regular semver to handle this as well as git branches for maintainers?

E.g. pip install QtWrapper==5 or pip install QtWrapper==6.

I've touched upon this in #293 (comment)

[fredrikaverpil]

Hm. Perhaps you meant to add Qt5.py next to the existing Qt.py file in the "Qt.py" repo. Then we'd just keep adding new QtN.py files as we go (where N is the Qt major version). I like this approach very much.

EDIT: No, that's probably not what you meant ... but I still kind of like that idea.

[mottosso]

Qt5.py which implies there could potentially be a Qt6.py down the road...

Yes, that's what I was thinking. Much like how there is PyQt4, PyQt5 (and presumably, PyQt6).

add Qt5.py next to the existing Qt.py

That's possible, worth thinking about!

[fredrikaverpil]

add Qt5.py next to the existing Qt.py

That's possible, worth thinking about!

We would have to figure out a way so that users can (pip) install a certain version of Qt.py and then also (pip) install a completely different version of Qt5.py though. Especially if the original Qt.py goes 2.x and starts supporting the transition between Qt5/Qt6. Some users may want to stay on 1.x but at the same time use the latest QtN.py.

I just realized, you also need to secure the project names going forward if you want new, separate repositories (such as the Qt5.py repository). If someone decides to fu** with us, they could just create Qt6.py, Qt7.py github repos and we would have an annoying problem on our hands.
And if we ever decide to move away from github, we'd have multiple repos to migrate.

[mottosso]

We would have to figure out a way so that users can (pip) install a certain version

That's not a problem, the setup.py can be called anything and we can have more than one, e.g. setup-Qt5.py

I just realized, you also need to secure the project names going forward

I think they're unique under the namespace "mottosso" though.

[fredrikaverpil]

I think they're unique under the namespace "mottosso" though.

Ah, yes. PyPi on the other hand...

[fredrikaverpil]

That's not a problem, the setup.py can be called anything and we can have more than one, e.g. setup-Qt5.py

Oh! In that case, I'm casting my vote on this one.

[mottosso]

Same repo would however complicate issue tracking, the README and perhaps most importantly releases. There is only one stream of releases per repository, and that's how we (currently) increment the version.

[fredrikaverpil]

True. Not so great, actually.

[fredrikaverpil]

@mottosso Please see #293 (comment)