Superseded by official PyQt5 wheels?

[The-Compiler]

Hey! I think this project was very useful back when PyQt5 didn't have official Windows wheels (thank you!), but I wonder if it's still needed? I can see various issues with it:

• People report PyQt/Qt bugs here because it sounds like an official PyQt thing.
• People find it on PyPI instead of the official PyQt5 and install it, and then either get an ancient Qt 5.3, or run into problems because of it not working (in the #pyqt IRC channel, we spent around 5h with someone having a "The specified procedure could not be found." error when importing PyQt5.QtCore, and it was really hard to find out that they didn't in fact install the official PyQt5).

So I wonder if there's still a reason for this to exist I'm missing? If not, maybe it should at the very least be deleted from PyPI, as Qt 5.3 is insecure, buggy, and in general not very useful nowadays?

Also, in either case, I think it would make everyone's life easier if this was clearly marked as unofficial and pointing to the official way to install PyQt via pip too.

[mottosso]

So I wonder if there's still a reason for this to exist I'm missing?

Indeed, this project fills the gap where PyQt5 isn't available for Python 2.7 64-bit on Windows.

But I take your point; I have no dog in this fight as I no longer use this project personally and you're in a much better position to know what the community thinks of it. I'd be happy to remove it from PyPI and mark this one as unofficial (which I'm honestly surprised it wasn't already, it definitely should).

I'll leave this issue open for a few days in case there is anyone out there who may object to the removal, as it may affect various projects where python-qt5 is included as a dependency.

Least I can do is mark it as unofficial.

Thanks for the feedback!

[AndresMWeber]

I literally just started using it as a dependency on a project just because it simplified CI installation based on Py2.7/windows installs greatly. If there's a similar PyPi package (not a wheel link etc that is more susceptible to change) that satisfies this constraint I'm all ears but until there's something that's on PyPi that services this issue I don't see why it should be removed.

I think it might be smarter to rename the project on PyPi to be a little more explicit as to its purpose aka python27-qt5 and do the proposed unofficial marking but removing it as a whole seems a bit overkill.

[The-Compiler]

See the readme - due to PyPI space restrictions you get a very old Qt 5.3 (released May 2014, we're at 5.9 now). So you should probably use the git link described there instead, which will probably continue working either way.

[mottosso]

Thanks for chiming in @AndresMWeber, one against one is a stalemate; nothing will change unless more folks chime in.

due to PyPI space restrictions

If it helps, it's possible things have changed since then. The official distribution weighs in at 99 mb, which would be enough for this project to upgrade to 5.9 and upload to PyPI (did a rough test, it weighs in at around 80 mb, zipped).

But I gather the main issue is the confusion in the community, mistaking this for something that should work on other OSs and versions of Python. That's possibly not as easy to fix from the PyPI release alone, though having said that there is a notice included for those that do try and install on a mismatched version of Python or OS though. I'm quite surprised it's an issue actually, but I have also seen posts circulating the interwebs from confused users.

[AndresMWeber]

It's not a deal breaker for me especially since I stand in a minority of users necessitating this workflow. If the community is really against this package I won't stand in the way of its deletion since I did write a docker image to deal with this issue, the package just circumvented having to use it and sped up my testing not to have to rely on that.

But thanks for mentioning the workaround, I'll be using that going forward. And thanks Marcus for creating this in the first place. Been lurking quite a bit of your work!

[altendky]

I haven't dug into the details but is there something we could do to make this not mix with official PyQt5? I was working with @The-Compiler to help this morning and roughly agree with him but I also have imagined making wheels for more Python versions and for the nightly zipballs. Would make it a lot easier for more people to test them. So, if I ever find time to do that then the basic issue still remains. How can we avoid difficult to detect issues? Maybe if we setup the builds (for official releases) Phil would put them on PyPi under PyQt5 itself? I dunno.

[The-Compiler]

I was wondering about what @altendky said too, but I'm not sure much could be done. Maybe this would go away when python-qt5 would use the same file structure PyQt5 does, so installing PyQt5 would overwrite everything properly?

For reference, this is what we've been dealing with - creating a virtualenv:

C:\Users\Florian>python -m virtualenv mess
Using base prefix 'C:\\Python36'
New python executable in C:\Users\Florian\mess\Scripts\python.exe
Installing setuptools, pip, wheel...done.

Installing python-qt5:

C:\Users\Florian>.\mess\Scripts\pip install python-qt5
[...]
Successfully installed python-qt5-0.1.10

For some reason it didn't work, but maybe only because the virtualenv wasn't in path and some Python DLL wasn't found:

C:\Users\Florian>.\mess\Scripts\python -c "from PyQt5 import QtCore; print(QtCore.QT_VERSION_STR)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: DLL load failed: The specified module could not be found.

Installing PyQt5:

C:\Users\Florian>.\mess\Scripts\pip install PyQt5
Collecting PyQt5
  Using cached PyQt5-5.9-5.9.1-cp35.cp36.cp37-none-win_amd64.whl
Collecting sip<4.20,>=4.19.3 (from PyQt5)
  Using cached sip-4.19.3-cp36-none-win_amd64.whl
Installing collected packages: sip, PyQt5
Successfully installed PyQt5-5.9 sip-4.19.3

And then the DLLs conflict somehow:

C:\Users\Florian>.\mess\Scripts\python -c "from PyQt5 import QtCore; print(QtCore.QT_VERSION_STR)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: DLL load failed: The specified procedure could not be found.

[BrenBarn]

It would be a shame if this were removed solely because of conflict with Python 3. As I see it the whole point of this package is to allow people to use PyQt5 on Python 2.7. If it's removed then we're back where we started as far as that use case.

The ideal solution would be for whatever tricks this package uses to be actually incorporated into the real PyQt5 so that it actually works on Python 2.7 without requiring this separate package, but perhaps that is unrealistic.

[The-Compiler]

I wasn't aware of the Python 2 situation, but from what I've read somewhere, it's deliberate that there are no official PyQt binaries for Python 2 - to motivate people to migrate to Python 3 (note Python 2 will be end-of-life in less than three years).

I still think this should be pulled from PyPI though as long as it's not possible to have an up-to-date Qt there. People can still install it from the github releases then.

[mottosso]

For some reason it didn't work, but maybe only because the virtualenv wasn't in path and some Python DLL wasn't found:

For completeness, I think you've got it by now, but the reason you are is because it won't work with Python 3, where PyQt5 is available via pip.

Could a solution could be to erase availability of python-qt5 for Python 3? I would have thought that was already the case via the setup.py. Is there another way for pip3 not to pick this version up?

Also, about this being an older version, pull requests are most welcome!

[mottosso]

I tried just now to upload this as-is to PyPI and got a space restriction error.. It also said it was submitting to something called legacy, which may suggest there is a newer version of it we could try submitting to with potentially more space allowance.

[altendky]

I don't know about source tarballs but with a wheel you should be able to specify the Python version that is supported.

https://wheel.readthedocs.io/en/latest/#defining-the-python-version

[mottosso]

Cool. I'm happy to see a pull-request of this.

[mottosso]

This repo is staying around, happy to see pull requests fixing the above mentioned issues.