Plans for PyQt6?

[BryceBeagle]

PyQt6 snapshots just came out. Currently they're nothing more than PyQt5 with some deprecated features removed. But it begs the question: will PyQt5-stubs support PyQt6?

[altendky]

I haven't looked hard at 6 but it sounds like there are the expected backwards incompatible changes you would expect from a major version, even when wrapping Qt5. (the enum stuff?) I imagine the answer being 'no it does not' but that it would be nice to. I have no idea on the timeline for Qt6 but i tend to like moving forward sooner than later so I will likely be on-board for working on the support. But for now I think getting cleaned up with 5 and seeing if we can work with Phil to get proper fixes upstream would be my priority. Then there's less for us to deal with (theoretically nothing, but...).

[BryceBeagle]

PyQt6 was just officially released: https://www.riverbankcomputing.com/pipermail/pyqt/2021-January/043485.html

Also of interest is that the OAuth stuff is now moved to its own package, PyQt6-NetworkAuth. The stubs would probably need to account for this

[TilmanK]

Guys, I just migrated one of my projects to PyQt6. No stubs. It's horrible ;)

Do you have any plans so far? Getting the PyQt5 stubs at least to work isn't that hard (tried it here: https://github.com/TilmanK/PyQt5-stubs), nevertheless, I think that you generated them somehow automatically in the past?

I know that they changed some arguments (pos is now position at some places), you need to use Enums now instead of class properties (i.e. QEvent.Type.Close instead of QEvent.Close) - so the PyQt5 hints aren't that useful either. Additionally, to what @BryceBeagle already wrote above.

[TilmanK]

I dug a bit and found that the generated stubs come with PyQt6 itself. So this is basically just a lot of manual work to merge them together, right?

Before I waste my weekend on this: Have you done anything yet for PyQt6? How do you plan on integrating it into this repo (do you even? - doesn't seem like the best thing to do)...

[altendky]

PyQt5 also came with stubs towards the end, but a lot of wrong stuff (and maybe some preference too). I think Phil got some things fixed in PyQt6, but it seemed like they wanted an item by item list of each issue and I didn't bother with that (beyond being able to diff against ours here and also our changelog). So, I expect there's a lot more work to be done with the stubs for 6. I haven't gotten to looking though. That said, I am rolling my way through Qt 6 support (https://github.com/python-qt-tools/qts for example) so maybe I'll get back to the stub layer.

Should we just move forward and update the upstream etc branches to six? If there's another PyQt5 release we can go back and branch off and deal with duplicative branches at that point (or just skip it and move on).

[TilmanK]

I don't know if it's a good idea to just update master, yet. From what I know, there are still some issues to be fixed in PyQt5 and PyQt5 we will be around for some time for sure.

I'd personally opt for a branch from which we can create a version exclusively for PyQt6. Supporting both versions at the same time will surely be a mess.

I'd be willing to provide an initial PR for that. What do you think?

[altendky]

Sorry, I didn't mean mixing the two together. I think the only difference in our ideas is whether we pre-emptively create separate branches for 5 and 6, or just move on to 6 and then create maintenance branches for 5 if we end up working on it again.

Anyways, the help would be appreciated. I think it's safe to go ahead and start a PR and we can redirect it to a different branch depending on what we decide? Are you familiar with the upstream branch that has exactly upstream stuff and is where we do the builds vs. the master branch where we maintain all our modifications?

ping @The-Compiler, @BryceBeagle

[altendky]

Mmm... I guess it would be nice to make it through the PRs and get a release out for that.

[The-Compiler]

Given that this repo/project is called PyQt5-stubs, IMHO we should even consider having a separate PyQt6-stubs repo. OTOH this would probably duplicate a lot of the CI infrastructure and such.

Since we essentially have a "fresh start" with the PyQt6 stubs, I still wonder if we can somehow start to automate the stub rewriting instead of doing it all manually (see #6). It looks like nothing has changed about the SIP stub generator part being written in C so far, so IMHO the best way to approach this would be parsing and rewriting the stub files (perhaps using something like LibCST.

I'd really like to find some time to tackle this myself, but probably that's just not going to happen in the next 6 weeks or so. I've talked with @RJ722 about this and he mentioned he'd be interested - maybe now would be the time? Happy to mentor a bit, if you want to give this a try.

[altendky]

I guess there's the option of just putting in the time upstream with PyQt6? Basically take the checking mechanisms and tests here and just get the official stuff right.

[TilmanK]

I like @The-Compiler's idea, but isn't that exactly what's our problem all the time? We don't want the stuff from the official files, because it's full of errors?

Wouldn't it be smarter to create a diff between two versions of the official stubs and create something from there?

[TilmanK]

On the other hand, thinking about it, that's exactly what we want. If we ignore the stubs completely, we could build a functional diff and work on things from there...

[The-Compiler]

I don't think it's useful to build a diff between PyQt5 upstream and our PyQt5 stubs and then apply that to the PyQt6 stubs. The problem so far has been that we've always fixed things on a case-by-case basis manually, rather than taking a more structured and automated approach.

If we had a more structured way of fixing problems (e.g. "take all signals and change their annotation from a function to a signal type"), we could fix all such issues rather than just a small part of them, and we could do so in a way it's easier to maintain, and easy to apply to both PyQt5 and PyQt6 upstream stubs, as well as easy to update for every new release of those.

[TilmanK]

I think we're talking about two things here. What I was thinking of, is to compare the current upstream version (independent of its mayor version) to our stubs so that we would be able to generate a diff of what has changed (added, removed methods, classes, arguments and so on).

What you suggest is useful independent of my thoughts ;)

Nevertheless, what is the right way to upgrade to PyQt6 apart from figuring out the differences (automatically or manually) and applying them to the current code base?

[The-Compiler]

There's an upstream branch in this repo, but the diff is going to be huge: https://github.com/python-qt-tools/PyQt5-stubs/compare/upstream..master

As well as some notes on what issues there are: https://github.com/python-qt-tools/PyQt5-stubs/blob/upstream/issues.md - but I doubt they are up to date currently.