search

python-qt-tools / PyQt5-stubs

Stubs for PyQt5
GNU General Public License v3.0
68 stars 31 forks source link

Upstream #196

Closed bluebird75 closed 2 years ago

bluebird75 commented 2 years ago

Update of the upstream branch (process was a bit messy, that's why there is in and out commit)

altendky commented 2 years ago

I retargeted this against upstream. I think that is what is intended?

So to do this you deleted all hints, extracted hints from wheels on PyPI, and ended up with this? I thought we decided there were not wheels available with some of the web stuff. Do we have any record of what versions were used? I think for all the lack of simplicity in the docker file it does have this.

bluebird75 commented 2 years ago

What I did is the following :

That's it.

The bias toward linux in the current stubs prevented those stubs to show up in the past.

Initially I also overwrote the official stubs in the upstream branch. However, between the MacOs, Linux and Windows wheels, we have 3 sets of differing files. The linux version remains the canonical version in my opinion, so it makes no sense to overwrite it with Windows specific version. So I did not touch it.

It's not clear how I can at the same time keep an upstream branch identical to the upstream, but have 3 differing version of the same file. Maybe for the differing platforms, I could use a prefix to mark the difference: QtCore-win32.pyi QtCore-linux.pyi and QtCore-macosx.pyi .

The differences are actually very small. I chose to integrate them directly in the master branch with #192

PyQtWebkit stubs are not available in any wheels. So, I did not touch them, I left them as they are.

The current process does not exactly accomodate for different stubs depending on the generation method (wheel or docker) and platform.

On the other hand, PyQt5 is not going to see any important release soon, so a manual process is OK.

bluebird75 commented 2 years ago

Your request makes sense, but it's very difficult to address in an automated manner. Even downloading stubs for another platform than the one you are running is not that simple. See for example https://discuss.python.org/t/pip-download-just-the-source-packages-no-building-no-metadata-etc/4651/14?u=bluebird75

And turning a set of differing platform stubs into one common set can not really be automated.

All in all, the cost automation looks way bigger to me than just performing the process manually once in a while when there is a release. This applies especially here because there are almost no PyQt5 releases planned.

bluebird75 commented 2 years ago

Thanks by the way for the approval.

altendky commented 2 years ago

The point was that arguments relating to just this repo and just pyqt5 are not applicable since this same situation applies to four cases, I believe. PyQt and PySide each for Qt 5 and Qt 6. So, in general, this will need to be dealt with regularly.

I think you want the binaries which seems to work ok from a single platform, even if maybe it involves a little manual entry of the platform tags.

$ venv/bin/pip download --platform win_amd64 --no-deps --only-binary=:all: pyqt5
Collecting pyqt5
  Using cached PyQt5-5.15.6-cp36-abi3-win_amd64.whl (6.7 MB)
  Saved ./PyQt5-5.15.6-cp36-abi3-win_amd64.whl
Successfully downloaded pyqt5
$ venv/bin/pip download --platform manylinux1_x86_64 --no-deps --only-binary=:all: pyqt5
Collecting pyqt5
  Using cached PyQt5-5.15.6-cp36-abi3-manylinux1_x86_64.whl (8.3 MB)
  Saved ./PyQt5-5.15.6-cp36-abi3-manylinux1_x86_64.whl
Successfully downloaded pyqt5
$ venv/bin/pip download --platform macosx_10_13_x86_64 --no-deps --only-binary=:all: pyqt5
Collecting pyqt5
  Using cached PyQt5-5.15.6-cp36-abi3-macosx_10_13_x86_64.whl (7.0 MB)
  Saved ./PyQt5-5.15.6-cp36-abi3-macosx_10_13_x86_64.whl
Successfully downloaded pyqt5
$ ls -la *.whl
-rw-rw-r-- 1 altendky altendky 6974219 May 18 22:41 PyQt5-5.15.6-cp36-abi3-macosx_10_13_x86_64.whl
-rw-rw-r-- 1 altendky altendky 8305724 May 18 22:41 PyQt5-5.15.6-cp36-abi3-manylinux1_x86_64.whl
-rw-rw-r-- 1 altendky altendky 6749398 May 18 22:41 PyQt5-5.15.6-cp36-abi3-win_amd64.whl
bluebird75 commented 2 years ago

Actually, I tried again yesterday right after responding to your comment and I succeeded this time, using exactly the same commands.

So that's an interesting first step. Automatic merging of 3 platform-stubs into one common stub is going to be more challenging, although not infeasible.

altendky commented 2 years ago

Sure, I don't offhand have a plan to suggest for fully automatic handling. But, steps like getting all the wheels, extracting all the files, identifying which vary across platforms and which don't (hopefully there isn't silly irrelevant noise), and identifying what files have been removed, seem pretty plausible and relevant to the whole suite of stub packages, I think.