Anaconda Spyder Qt library error on launch - python

When launching Spyder from the Anaconda python installation on Linux Mint 13 I get the following error:
Cannot mix incompatible Qt library (version 0x40801) with this library (version 0x40805)
Aborted
$PATH is
/home/ron/anaconda/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
Has anyone found a work around?
Anaconda web-site indicates that Spyder may not launch correctly on Linux machines.
http://docs.continuum.io/anaconda/
*** Resolved
I am a little sheepish. Discovered that I installed Anaconda as sudo. Reinstalled as indicated in documentation and everything works fine. Thanks everyone for the help.

I use anaconda 1.8 on kubuntu alpha. It uses qt 4.8.5. I can see it with
find $ANACONDA/lib -name '*.4.8.5'
My system qt libs is 4.8.6. I can see it with
find /usr/lib -name "*so.4.8.6"
If Your system qt version is 4.8.5, and anaconda is 4.8.1 -- maybe You can just update anaconda? Try to run
conda update conda
conda update anaconda
Edit
It seems that the problem is spyder picking up Your system libraries. I tried to sheild the libs using evnironment variables LD_LIBRARY_PATH and various qt-related. But nothing works. However simple copying system libs to $ANACONDA/lib solves the problem.
Go to $ANACONDA/lib and move all *.4.8* files to another dir. Then go to /usr/lib/x86_64-linux-gnu (are You using 64 bit?) and copy all *.4.8* to $ANACONDA/lib. That's it: run spyder!
The qtlibs are usually stored as files and links: for example if there's a libQtGui.so.4.8.6 file then there's also a symbolic link libQtGui.so.4.8. You have to copy/move links too.
Edit 2:
There's a suggestion to
unset QT_PLUGIN_PATH
I tried to set it to nothing export QT_PLUGIN_PATH=, but didn't try to unset it.

(Spyder dev here) Just for the record, this is a know bug in Anaconda that hopefully will be fixed in its next version (to be released in October/2014).

For me, the best solution was (inspired by #Adobe's answer) to go to the directory in which Anaconda was installed, then the subdirectory lib and to move all the files libQt* out of the way (I moved them to a temporary subdirectory I created for the purpose). Anaconda will now pick up the system libraries. I expect there will be a problem when I update Anaconda and it installs new Qt libraries, but that's for later.
My version is conda 3.9.1 with python 3.4.3 and qt 4.8.5, installed on Debian testing (current as of today) with libqtcore4 version 4:4.8.6+git64-g5dc8b2b+dfsg-3; the architecture is amd64.
Unsetting QT_PLUGIN_PATH and/or setting it to empty did work in the first instance, in that it allowed me to start spyder, but it has some disadvantages. Most importantly, whenever I tried to plot something using matplotlib and inline graphics, I got the error message "it seems the kernel died unexpectedly" instead of the plot I wanted.

Related

QT Binaries Problem : Unable to use PySide2

I'm getting the following error when I try to run my code where I want to use PySide2.
objc[18673]: Class RunLoopModeTracker is implemented in both /opt/anaconda3/lib/python3.8/site-packages/PySide2/Qt/lib/QtCore.framework/Versions/5/QtCore (0x11c3c0288) and /opt/anaconda3/lib/libQt5Core.5.9.7.dylib (0x1207e3a80). One of the two will be used. Which one is undefined.
QObject::moveToThread: Current thread (0x7fe94dc18af0) is not the object's thread (0x7fe94df34560).
Cannot move to target thread (0x7fe94dc18af0)
You might be loading two sets of Qt binaries into the same process. Check that all plugins are compiled against the right Qt binaries. Export DYLD_PRINT_LIBRARIES=1 and check that only one set of binaries are being loaded.
qt.qpa.plugin: Could not load the Qt platform plugin "cocoa" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: cocoa, minimal, offscreen.
Abort trap: 6
Unfortunately I have no clue what this means and what to do about it, I tried googling it already but nothing useful has come up!
I'm using Python 3.8.5, PySide 5.15.2 and I'm on Mac OS 10.15.7. Thanks for any help!
I had the same You might be loading two sets of Qt binaries into the same process error with my Qt app when using PyInstaller for packaging.
Using an isolated venv for development, created from anaconda3, everything worked fine! But when the PyInstaller pulled in PySide2 and whatever else it needed from my various env PATHs, the anaconda3 versions of libQt5* that were brought in now conflicted with PySide2 (from my requirements.txt)
After a lots of debugging which dylibs are actually loaded by whom and reading all the SO articles, it slowly dawned on me that anaconda3 was the culprit!!
There is precedent for conda package management conflicting with pip based workflow.
Carlos Cordoba, a Spyder IDE maintainer, has helped folks resolve issues with installs, which while adjacent to our problem, gets to the essence of the anaconda3 && Qt conflict. Have a look at his comments in the accepted answer
I solved my problem by:
Removing anaconda3 from my env paths (like $PATH) and .bashrc, essentially making it invisible.
Deleted old anaconda3 venvs used to develop my app
Installed a fresh python3.9 from python.org (much more lightweight than anaconda), added it to my $PATH in .bashrc, to make it my primary python3
Re-building venvs to test, I redid PyInstaller packaging and ran the generated app, now this error is gone!
For debugging I set export DYLD_PRINT_LIBRARIES=1, which no longer shows multiple conflicting QtCore dylibs being loaded.
What DID NOT work for me, but was very commonly seen on SO:
pip install opencv-python-headless. Ya nope.
unset QT_PLUGIN_PATH. This didn't stop the loading of the conflicting libQt5Core
any combination of uninstall & reinstalling anaconda3, or PySide2.
To solve your problem, because /opt/anaconda3/lib/libQt5Core.5.9.7.dylib is the root of the conflict, I recommend that you uninstall (or move anaconda3 out of the way) and use a python.org version of python3.8 OR ... use anaconda3 in venv (which is isolated) and install your dependencies directly with pip

Spyder on MacOS. Typing is very laggy

I am using Spyder with Anaconda on macOS. I have already updated Anaconda and Spyder to version 4.2.0 (4.2.1 was not found). The problem is now, that if I am typing in Spyder it takes about one second until the letters appear, which is very annoying. Is there somebody who also has this problem? Or does somebody have a suggestion on what might be the problem?
Had the same exact issue with Spyder 5.0.0, on Catalina; editor being very laggy (the console was fine).
Solution worked for me: Disable Kite!
From the top menus:
Python > Preferences... > Completion and linting,
Deselect any option that calls Kite:
Notify me when Kite can provide missing completions (but is unavailable!)
Enable Kite provider
PS: Tried pyqt solutions with no success (this now generates warnings in the terminal every time I open Spyder).
(Spyder maintainer here) There are two main causes of this problem:
We had several memory leakages and other serious inefficiencies that were causing a lot of sluggishness in the editor. Most of them are fixed in our 5.1.5 version, released in September 2021. Other improvements will come in 5.2.0, to be released in November 2021.
If you're still experiencing this problem with those versions, it could be because you're in Big Sur. The only way to get a fix for that is by using our mac OS installer
I'd like to chime in and say I'm getting this on Catalina (not Big Sur).
Using Spyder 5.0.5 seemed to fix it.
-- Edit
No it didn't. I'm on Catalina and it's still laggy as hell. Using v5.0.5
read: https://github.com/spyder-ide/spyder/issues/14218
One solution suggests downgrading pyqt and pyqtwebengine.
vancromy commented on 17 Nov 2020 I just pip installed pyqt==5.12 and pyqtwebengine=5.12 in my base conda environment and noticed a
substantial decrease in the latency! Still a bit of latency but not as
pronounced as before. :)
Note: Please don't use this solution if you're using Anaconda because it could break your environments.
tools -> reset spyder to factory defaults
and it worked
Two years later, and this is still an issue. Sypder recommends installing from their DMG, which resolves the issue.
What I did was create my virtual environment and instead of installing Spyder there, I installed:
conda install spyder-kernels=2.2
v2.2 is important because otherwise there may be conflicts and it won't install.
Then, deactivate your environment and launch Spyder from the conda base environment.
In the bottom right of Spyder is text with the environment name. For example, mine says: conda:base(Python:3.9.12)
Click that and then "Change default environment in Preferences"
In the Preferences frame, under Python Interpreter, select Use the Following Python Interpreter
From the drop down menu, select the one with the name of your environment. It should look something like:
/Users/YourComputerName/opt/anaconda3/envs/environmentname/bin/python
Click Apply, then okay.
Spyder works flawlessly when you install its standalone version and not from the anaconda distribution (not sure why anaconda is still not fixing it).
If you want to make use of conda virtual environment with Spyder standalone IDE, see the solution detailed below. It worked for me very well.
https://medium.com/#apremgeorge/using-conda-python-environments-with-spyder-ide-and-jupyter-notebooks-in-windows-4e0a905aaac5
# install Anaconda and create a new conda environment
conda create -n env_name python=3.7.4
# activate environment
conda activate env_name
conda install package_name
# get path of the environment
python -c “import sys; print(sys.executable)”
# install spyder-kernels (version >= 2.3.0 and <= 2.4.0)
pip install spyder-kernels
# copy the env path in Spyder IDE and restart Spyder IDE
Spyder -> preferences -> python interpreter -> use the following Python interpreter -> choose from the drop-down list or copy the env path
Experienced this issue on MacOS Mojave via Anaconda. Upgrading both Anaconda (v4.10.3) and Spyder (v5.0.5) didn't help. Ended up following this guide, which suggested upgrading PyQt5 and PyQtWebEngine modules. A warning was produced upon upgrading:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
spyder 5.0.5 requires pyqtwebengine<5.13, which is not installed.
spyder 5.0.5 requires pyqt5<5.13, but you have pyqt5 5.15.4 which is incompatible.
Despite the incompatibility warning, I no longer experience latency.
Note: Please don't use this solution if you're using Anaconda because it could break your environments.

Anaconda update for Spyder has failed

Windows 10, 64 bit Anaconda 4.2, Python 3.5
I opened Spyder today to do some work. (so much for that idea, several hours later)
Spyder gave notice that there was new (3.1) version. I was on 3.0.2
So, I tried updating
conda update spyder
but it told me that it needed to DOWNGRADE it because of dependencies (I think, I wasn't taking notes at the time - so much for optimism)
Then I tried to update conda but that made things worse at this point, Spyder wouldn't start at all.
So, I uninstalled everything. At least, I think I did.
I went through Windows Programs and looked for anything that looked like it might be part of Anaconda, python, or Spyder.
I tried reinstalling Anaconda.
I got the 3 error messages about menus, path, and directories (there's a bunch of tickets on those). My path is short (800 characters or so) and my user name is in English.
I uninstalled and tried again.
Same results.
I created and ran the Fix.bat
"C:\My_Stuff\Program_Files\Anaconda3\pythonw.exe" -E -s "C:\My_Stuff\Program_Files\Anaconda3\Lib\_nsis.py" addpath
"C:\My_Stuff\Program_Files\Anaconda3\pythonw.exe" -E -s "C:\My_Stuff\Program_Files\Anaconda3\Lib\_nsis.py" mkdirs
"C:\My_Stuff\Program_Files\Anaconda3\pythonw.exe" -E -s "C:\My_Stuff\Program_Files\Anaconda3\Lib\_nsis.py" mkmenus
and that at least gave me my menus.
From a command prompt (either Anaconda or Windows),
conda list
shows no packages.
Spyder and Anaconda Navigator do not start ("This application failed to start because it could not find or load the Qt platform plugin "windows"
in "".)
Typing python from a command prompt (either one) appears to work and references Anaconda 4.2.0
I'm going around in circles.
Any help appreciated.
Craig
I had posted this on Github too, as I ran into a larger problem while trying to get my system back.
The last comment from that thread (https://github.com/conda/conda/issues/4369) is repeated here:
I have, I believe, successfully installed Anaconda 4.2 64bit Python 3.5 version
I uninstalled the software again using the Windows 10 uninstall from Programs and Features.
I manually removed the Anaconda paths from the user PATH variable.
I manually removed the Anaconda folder from the Startup menu.
I manually removed selected references to Anaconda in the registry.
(I did not see the Anaconda clean program until later - https://docs.continuum.io/anaconda/install)
I rebooted.
I installed from the exe I had downloaded last year (4.2)
This time, I installed for all users, not just me.
Testing
`conda list
returns many packages. Yeah!
Calling python from a command prompt works too.
Spyder starts and remember my previous project, so that is nice too.
I think I can work again.
I may need to upgrade some packages, so hopefully that will go well too.
Craig

How do I change the kernel/python version for iPython?

I have installed iPython using pip in OS X 10.10, and it gave me the "ipython" and "ipython2" commands, which run great, but which use OS X's default python version 2.7.9. I downloaded and installed the latest release of Python3.4 and can load it with the command "python3," but cannot find a way to get iPython to use this version of python. The iPython Web site states the package can be used with python versions 3.3 and above, but I cannot find any instruction on how to change the default python version used.
So far I have found that the jupyter package for iPython has a kernel specification in /usr/local/share/jupyter/kernels/, which is just a folder called "python2" containing a json file that points to the system's python 2.7.6, but altering this to point to the new python3.4 installation does not work. My guess is this configuration is for the ipython notebook.
I've also tried the approach here: ipython reads wrong python version
In doing so I've duplicated the ipython2 command in /user/local/bin/ and edited it to use the python3 interpreter located at /Library/Frameworks/Python.framework/Versions/3.4/bin/python3, however, this gives me an error "ImportError: No module named 'IPython'," which suggests the python3 installation does not have ipython installed.
To tackle this, I've tried uninstalling ipython and reinstalling it using pip, but it just targets the system's Python 2.7 installation and does nothing for python3.
Does anyone know how to configure iPython to use a different python version, or even install a separate ipython installation for python3? Ultimately it would be nice to quickly switch back and forth depending on my needs.
I just found the answer. In essence, this stems from not understanding the python installation layout and how resources are separated between installed interpreters. It appears each python version will have its own repository of tools, and the current "pip" command I had installed on the system was mapped for use with python 2.7, so all libraries, tools, and other details it managed where available only to python 2.7. This included iPython.
I thought that installing python3 would make all these libraries available to the new interpreter by default, but it appears the system keeps them all separate (which makes sense). The main issue here was continuing to use "pip" which targeted the old installation, instead of the new "pip3" command included with python3. By using pip3 to reinstall iPython, I was able to get iPython3 installed properly.
Unfortunately this setup means needing to re-download other libraries, but that's not too difficult.
It might seem like a trivial issue in hindsight, but this had me completely stuck. I hope this helps someone else in this situation.

Cannot Open Python. Error 0xc000007b

I have recently been learning Python 3. I have had no problems on my netbook (32bit Windows 7) I with creating small simple programs. When I installed it on my netbook I had no problems, but now that I've been getting into it I want to install it on my desktop and I have one.
My desktop is a 64 bit OS running Windows 7. Like I did with my netbook, I went to download Python and install the 64 bit edition.
After installing it, I went to open up Python CLI and GUI and no luck. It gave me this error.
"The application was unable to start correctly (0xc000007b). Click OK to close the application"
I also tried reinstalling, but not luck.
I suspect a missing .dll but I am not completely sure. Does anyone know what is keeping me from opening Python and how do I fix it?. I want to resume my work as soon as possible.
That is the NTSTATUS error code for STATUS_INVALID_IMAGE_FORMAT. Almost invariably that means that the loaded is attempting to link a 32 bit DLL into a 64 bit process, or vice versa.
If you want to attempt to debug this then the tool of choice is Dependency Walker. You open the python.exe executable file in Dependency Walker and use the profile menu to start it up with logging of the load events. Somewhere along the way there will be a failure and you'll be able to see which module is causing that failure. That will hopefully point the way towards a resolution.
However, attempting to debug this may be a waste of time. It will probably better to uninstall the existing installation, and try to re-install. Perhaps picking a different Python distribution.
I note that you have selected a 64 bit version. Now, support for 64 bit extension modules is not as strong on 64 bit Python as on 32 bit Python. It does exist, but they modules can be harder to come by and install. You might consider installing a 32 bit Python next time round.
Please make sure that Python3.dll is the same version and the same architecture (32/64) with python.exe. I fixed this error via replacing it with 32bit version.
you should delete the old path of python in "Environment Variables" and enjoy ;)
As janne-karila mentioned, and for Python 3.5, Microsoft Visual Studio 2015 redistributable (in this case the 64 bit version)
This probably won't answer your question, but my answer is for a very specific case when you "Refresh Windows without affecting Files" to fix your Windows 8.1 PC.
If you do that, You'd get this error when you try to run Python after the windows refresh.
To fix this error, simply re-install PY at the same folder where your python was install before you refreshed windows. If you try to install it any other folder like username/appdata/... folder the PY installer would be stuck in initialization.
You may also get another error saying "api-ms-win-crt-runtime-l1-1-0.dll is missing". To fix, go to the windows.old folder and get the dll file ith the above name and paste it in the PY folder. Also like others have suggested, make sure Microsoft Visual Studio 2015 redistributable is installed.
Encountering this error after a windows refresh is so rare, that no one else seemed to have experienced according to google searches, so I though I share it here for that rare unlucky person.
Apparently the error code stands for STATUS_INVALID_IMAGE_FORMAT (source), and it looks like it's not specific to Python. You can try reinstalling the program, rebooting, running CHKDSK /r (source). It might also have something to do with the Microsoft Visual C++ redistributable package, as Janne Karila and this thread suggest.
This stackoverflow question also looks like it has some useful information.
I too faced this problem. So I uninstalled python3 64-bit version and installed 32-bit version, after that i am able to launch python3 in windows 8 successfully. (i have a 64-bit laptop).
Simply, download the last version of Microsoft Visual C++ redistributable package ..
I had the same problem ..
I have the same error found. Using dependency walker, I found tons of DLLs missing. Rather going for copying all the DLLs I went with virtual environment. It will create another environment for Python.
First, install python normally. Copy, the Python.exe path. In my case, it is
C:\Python\python
It will be used to install Python libraries. Then, using command prompt, I used pip to download and install virtualenv (Virtual environment). To do that, change the directory to where pip.exe is, which is in Scripts folder. Now, run the following to install virtualenv:
C:\Python\python pip install virtualenv
It will install Virtual environment.
Now, create a folder to hold virtual environment and change directory to that folder and run to create the following to create an environment:
virtualenv --no-site-packages [environment name]
It will create the Environment.
Now, change subdirectory to Scripts in the [environment name] folder. There is a activate file run it, in my case it is like:
C:\Python\virtualenv\env\Scripts activate
env is the [environment name] here.
If you activate it, every command will look like:
(env) C:\Python\python
This ends here. Now, you can install any python library using this. Do whatever, you want using Python.
Also, to deactivate the environment same deactivate.bat is in the scripts folder.
For me the issue was, I had installed 32 bit version on a 64 bit machine. Hope it helps someone out there.
Like many have said, Windows cannot load python.exe itself or one of its dependent DLLs because of INVALID_IMAGE_FORMAT:
python.exe is of unsupported bitness. 32bit on 64bit Windows is supported. 64bit on 32bit system is not (solution: install 32bit python, bye).
python.exe or one of its DLLs is corrupted (probably not)
one of the dependent DLLs is not of the same bitness as the EXE:
python.exe (say, 32bit) requires python*.dll (python3.dll or python27.dll). It installs that into Windows System32/SysWOW64 folder. The DLL is of correct bitness (32bit).
Something else overwrites that with 64-bit version, or places a 64-bit version somewhere in the search PATH.
When you run python.exe (32bit), Windows searches for python*.dll, and the first one it founds is the 64bit one. 32bit EXEs cannot normally load 64bit DLLs.
Typical examples:
TortoiseHg installs its own copy of python (both .exe and .dll) into its own folder and adds itself to PATH. The bitness can be different (say, 64bit) and usually matches platform bitness.
Another installation of Python with a different bitness somewhere else overwrites the DLL (it shouldn't, they have different System32s, but who knows)
Diagnostics:
Dependency Walker marks 64bit DLLs with 64bit icons. Verify that icons for python.exe and python*.dll match. Right click -> "Show full paths" to see where the DLL is taken from.
Simple solutions:
Maybe you have another, functioning copy of Python somewhere else? Check it.
Reinstall Python, preferably in the platform version (64bit for 64bit OS, 32bit for 32bit) Yeah, that's what many are saying, but now you know why this is needed.
Remove offenders from PATH. While this maaaay fix your Python, this will break the offenders and some (TortoiseHg explorer plugins) need the PATH. So maybe compromise with them and choose #2.
In my case I was installing both the 32 and 64 bit versions of the python msi. They both install to the same folder, c:\python32. I thought msi's would prevent those kinds of conflicts, but no.

Categories