-
Notifications
You must be signed in to change notification settings - Fork 434
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ModuleNotFoundError: No module named 'PyQt5.sip' #875
Comments
I had a go a few days ago at generating the necessary PyQt5.sip module by rebuilding from source using the official instructions here: However, despite following these instructions the module was never built. This isn't the place to solve that particular problem, I'm posting this for reference since this is going to hit increasing numbers of Linux users as people upgrade to distros that lack this vital file and not everybody has the skills to do source builds. However, if Mu can be patched to remove the dependency on PyQt5.sip that would be great or alternatively an AppImage that avoids the problem would also be useful. |
@tim1mw, I'm not really sure if that is possible or even makes sense, being unfamiliar with Mu, by itself, does not depend directly on Can you isolate and reproduce that failure in your system? I mean:
If it fails, my initial feeling is that whoever packaged/distributed PyQt5 forgot something... Or maybe I'm mistaken (there's that serious possibility!) and something should/must be approached in a different way. My 2c. |
How exactly did you install Mu and it's dependencies, and could we get the terminal output? The more detail in all the steps taken the more useful it will be for us to locate the problem. If you used |
@tmontes I get this from the test: Traceback (most recent call last): So this suggests this is caused by the change to the build defaults in sip mentioned in my first post, with a knock on effect to the distro packages.. It isn't just Mageia 7 and Mu there's quite a lot of reports around the web from other python packages with the same problem after people upgraded to a distro version with the latest sip and PyQT5 packages. What worries me is that manually rebuilding sip and PyQt5 from source with the correct build options still doesn't generate the missing file. So while this isn't necessarily Mu's problem any help and thoughts from here are appreciated. I'll certainly see if I can feed back a bug report to Mageia, though it seems the problem may be upstream if the issue is that the new build option to generate this file doesn't actually work. @carlosperate , I uninstalled the version I had and then did a user install in an entirely new user account to try and keep things clean. I might have time to set up a VM at the weekend and do an even cleaner version, but no promises on that. [tim@flossie ~]$ pip3 install mu-editor --user |
Interesting, that's different from the exception you originally observed:
I understand your point of view. My linux testing tends to be very light, but as of the most recent stable/long-term-support versions, and in my observation, Mu happily installs and runs on Debian, Ubuntu, and Raspbian. Are you wondering whether these distributions will "bring us" troubles too, in the future? Thanks! :) |
@tmontes basically yes, this is what I'm wondering. For the distos that work for you which version of PyQT5 do they have installed by default? The problematic change to the build script was introduced in v5.11. Some of the posts I'm seeing suggest that removing the distro supplied version of PyQT5 and the letting pip install it instead may help, but that hasn't worked for me so far (and has knock on issues because of system dependencies). However, this isn't very user friendly, ideally it would be nice to see a Mu appimage for Linux that avoids these issues. I'll give this a go with a virtualenv next when I have a moment, perhaps that will solve the problem. This is particularly frustrating since we are doing a Micro:Bit/Mu session at the local Linux user group in a few days time. Right now, I'm only able to run Mu on windows. |
My experience is quite the opposite, actually, and very seamless (but not 100% beginner friendly!). I just checked an Ubuntu 18.04 VM I often use:
I wonder if something like this would work for you under Mageia (which I've never tried):
|
Taking out QT as a whole kills the entire KDE desktop, not really an option for me as a KDE user. It also knocks out VLC, Libreoffice, VirtualBox and a load of other common apps, so even people on a no-QT desktop would have issues doing that. The HP print manager tool also has a dependency on PyQT5 so pulling just that isn't really an option if you have an HP printer. However, I gave this a go with the distro QT installed, the procedure needed a slight change to account for differing file paths: python3 -m venv mu-venv And it seemed to work, so that's good news, hopefully anybody else who encounters this problem will find this issue and use that work around. Thanks for the advice! |
I really didn't mean "go ahead an uninstall Qt". Instead I meant "regardless of system-wide Qt, pip installing Mu will bring in an independent Qt implementation" (except on the Raspberry Pi where the system Qt is accounted for). Maybe we can improve the installation guide here -- https://codewith.mu/en/howto/1.0/install_with_python. What is your feeling on that? Or maybe you didn't know about it, and we need to find better ways of helping people find it. :) PS: It's good that it worked for you! :) |
Hi @tim1mw, I suppose after having installed Mu per the linked guide in my previous message things have been running smoothly for you. If that is the case, could you please close this issue? If not, please let us know what is failing or should be improved, in your perspective. Thanks. |
@tmontes Sorry I've not updated this further, I've had a very intense few months at work. The virtual environment has done the trick as mentioned in my earlier message. However that doesn't really feel like a long term solution. It may still be that this is really a packaging problem, but it seems to be one that may become more common. I think this can close for now, if I find out more I may post again or open a new issue. |
@tim1mw, thanks for sharing your feedback. I do agree that installing this way (virtual env + pip install + etc) is not "the solution" for Mu's target audience of beginners; it is very important, though, and mostly directed at Mu contributors / developers. And it does work (nearly everywhere, by the way), as you can attest. :) Software distribution is more complex than many would wish for. In an ideal world, Mu would be available for single click installation on each platform's native "application catalog" -- that's something that would serve beginners well. While the Windows and macOS targets are somehow confined, the Linux universe is much richer and having Mu in each and every distribution's "native" software repositories will never happen -- there has been some work in having it integrated into the Debian and Fedora repos, but I'm not 100% up to speed on that status / progress. It is available in Raspbian for the Raspberry Pi, though! :) Having said all of this, if you or someone else is willing to contribute (and maybe figure out how, along the way!) to having Mu integrated into Mageia's repositories, I'll be glad to walk you through the existing Mu's packaging process. :) Again thanks. |
@tmontes I believe the work on getting Mu into Debian is finished, this was being done by a friend of mine, he gave a talk on the process to our local LUG a few months ago. As for packaging for Mageia, very very maybe, the work needed to do the Debian build was considerable, I think it took the best part of a year (admittedly fitted in between other commitments) because of the missing and very complex dependencies. That was partly caused by the Debian requirement for everything to be built from source, so he had to sort out an entire tool chain to build the micropython interpreter binary. Mageia may not be as complex since I suspect they won't insist on that. |
Coming to this two years later, and hitting the same issue (and others; Mu installation via pip apparently doesn't work on distros based on Ubuntu 21.10 (where Python is upgraded to 3.9; doesn't work at all on KDE), I think it would be really helpful to mention that Mu is available via https://codewith.mu/en/howto/1.0/install_with_python As it is, I tried for two hours on three different computers, all with no success. I realize I could have made it work with |
Hi Another Mu user here.. What version did you install via apt? see this comment fro the method i followed which has worked well for me so far! |
Oh, that's probably true; I didn't really care if I installed the newest version. |
I've installed Mu using pip3 on Mageia 7, I'm getting the following error:
Traceback (most recent call last):
File "/usr/local/bin/mu-editor", line 6, in
from mu.app import run
File "/usr/local/lib/python3.7/site-packages/mu/app.py", line 29, in
from PyQt5.QtCore import QTimer, Qt
ModuleNotFoundError: No module named 'PyQt5.sip'
I've got the python3-pyqt5-sip distro package installed (4.19.16), but that doesn't contain PyQt5.sip and a search of the package repository suggests this file is no longer available in any standard distro package. Digging around the web there seem to be quite a few bug reports against various applications suggesting that this file is no longer packaged in the latest distros.
The answer appears to be in this post:
https://raspberrypi.stackexchange.com/questions/87125/installing-pyqt5-on-raspberry-unable-to-imoprt-pyqt5-sip
It seems that PyQt5.sip is no longer generated by the default settings in the sip build process, it has to be explicitly configured and presumably my linux disto and quite a few others aren't doing this. Using:
pip3 install --user -I PyQt5-sip
To overwrite the distro packaged version with 4.19.17 doesn't help. I'm guessing if I go and make my own build of PyQt5.sip that will solve the problem but that will be a task for another day.
The text was updated successfully, but these errors were encountered: