PR: Unify and cleanup CI infra, improve robustness and test Python 3.9 and PyQt6

[CAM-Gerlach]

• Upgrade CIs, unify and skip early
  • Port many improvements from docs + submanager
  • Set run/no run vars in matrix and ifs on steps
  • Unify to one run script
  • Unify to one runner job
  • Modernize and fix issues in ci and script
  • Test and fix any issues
• Use stricter, more informative runtests and python invocation
• Install QtPy from built wheel to test packaging
• Try previously skipped configs to determine if working
  • Test PySide2 5.13 with conda
  • Test Pyside2 5.15 pip wheels on Windows
• Try using native Python pip with venv for non-conda builds? Maybe later
• Add Python 3.9, fix any warnings & add tags
• Try Python 3.10, fix any issues & add tags Test deps on conda not yet officially compatible
• Add PyQt6 to CIs
  • Add to matrix
  • Fix/update/refine a number of out of date/erroneous test skips

Resolves #253
Part of #233

[CAM-Gerlach]

Ready for final review @dalthviz

The only skips I needed to add were for a couple PyQtWebEngine components which are not yet available with PyQt6, since the PyQtWebEngine separate package is not (yet?) released for Qt6 (basic QtWebEngine works; not sure if that is expected or merits further investigation) and [fixed by installing the renamed package] matching the PySide6 skips for UIC on Linux CIs and winextras on Windows; the other test skip changes all actually fixed or narrowed out of date/incorrect/overly broad existing skips, which modestly increases overall coverage.

Similarly, the only platforms PyQt6 is skipped on is Python 3.6 non-conda on macOS and Linux, as wheels for PyQt6 6.2 are apparently not (currently) available there. Other than that, I substantially increased platform coverage, e.g. added coverage for all platforms and Python versions for the conda Pyside2 packages and Pyside2 5.13, added tests of PyQt 5.15 and PyQt + Windows + Py3.8/3.9, and filled in gaps in patch version coverage, plus other issues.

Finally, more broadly, it is now much easier to add new Python, Qt and PyQt/PySide versions, and platforms, conda use and more to the matrix without having to duplicate workflows or test scripts, as well as gain precise control over whether and the versions of each tested for each combination, all in one place.

[dalthviz]

Thanks @CAM-Gerlach for all the work! I left some comments regarding QtWebEngine (which maybe will allow us to test it with PyQt6), the matrix values for Python and the segfaults for the uic module

[dalthviz]

Also, @CAM-Gerlach I saw this PR was done in a branch from the actual repo and not from your fork. Was that necessary for some reason? Maybe due the changes in the Github Actions workflow?

[CAM-Gerlach]

Also, @CAM-Gerlach I saw this PR was done in a branch from the actual repo and not from your fork. Was that necessary for some reason? Maybe due the changes in the Github Actions workflow?

Yes, that's it; normally I never create branches on upstreams except for this reason. I'm not sure if its changed, but at least previously (apparently for security reasons) GitHub actions workflows would use the upstream repo's workflow file, not the fork's file, or not trigger at all, and I had to do the same thing on previous PRs adding/making changes to workflows (e.g. PR #208 ) or Actions wouldn't always work.

Has that been your experience, or is that not necessary anymore? It would be nice to not have to do that anymore.

[dalthviz]

I think we changed the workflow file for dropping Python 2 drop but since that only removed testing instances not sure. Although, to add PySide6 testing, I think that was done from a branch fork so maybe is not needed anymore but no idea for sure to be honest

[CAM-Gerlach]

Yeah, I was thinking of the PySide6 PR as well, as it looks like that did work fine. It seems the problem, assuming it still exists, is likely only limited to creating new workflow as opposed to making changes to an existing one, so for most workflow-related things an upstream branch shouldn't be needed in the future, thanks.

[ccordoba12]

Thanks @CAM-Gerlach!

[dalthviz]

Should the branch be deleted @CAM-Gerlach ?

Edit: Also, checking seems like now our coverage is set to 0%: https://coveralls.io/github/spyder-ide/qtpy?branch=master?

Could you check that please @CAM-Gerlach ?

[CAM-Gerlach]

Should the branch be deleted @CAM-Gerlach ?

Yup, thanks! Done.

Edit: Also, checking seems like now our coverage is set to 0%: https://coveralls.io/github/spyder-ide/qtpy?branch=master?

Huh, I had previously verified that the coverage reports and the coveralls output all looked good (after some fixes to get things working), and I can confirm they still do in the latest build, so I'm not sure why coveralls isn't seeing the coverage other than it not handling coverage from the installed package (vs. the local source) properly. I opened #267 and am getting on this right away.