I've never seen an error like this and don't know where to start. I installed opencv with
conda install opencv
and am running Ubuntu Linux 18.04 using a conda environment named fpn. How should I even approach debugging this?
Traceback (most recent call last):
File "test.py", line 5, in <module>
import cv2
ImportError: /home/s/miniconda3/envs/fpn/lib/python3.7/site-packages/../../././libgnutls.so.30: symbol mpn_add_1 version HOGWEED_4 not defined in file libhogweed.so.4 with link time reference
There seems to be a problem with the recent releases of opencv packages for Conda. I have tested all the 4.x releases and found that the problem occurs starting from 4.3. Unless you really depend on >=4.3, forcing a version prior to 4.3 solves the problem,
name: test
channels:
- anaconda
- conda-forge
dependencies:
- python>=3.8
- opencv<4.3
in my cases this installed 4.2.0. Importing cv2 in Python works fine then. Note that using conda update didn't work for me and I still got the error, but I had to first remove the environment and then re-create it. I think this behavior indicates that the error is rooted in some dependency of opencv, which is not properly down-graded when conda update is used.
I don't consider this a true solution, but installing via pip with
pip install opencv-python
does work with no problem. Shouldn't there be a way to install with conda?
The problem seems to happen with a mix between conda-forge and anaconda packages, which aren't compatible.
I encountered the same problem; the ultimate issue was having conda-forge configured with lower priority than anaconda. This caused the anaconda packages, which were incompatible, to be installed when there was an option.
This is, of course, a bad idea - since conda-forge assumes anaconda availability, but not vice versa
Related
Importing winshell (version 0.6) causes the following error:
>>> import winshell
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Python39\lib\site-packages\winshell.py", line 32, in <module>
from win32com.shell import shell, shellcon
ImportError: DLL load failed while importing shell: The specified procedure could not be found.
I finally managed to get Anaconda to start working by executing the line:
pip install pywin32==300
I had to do it twice, because the first time it went for 301, not 300. The second time then dropped it to 300. This was from the Anaconda for Windows installer downloaded just two days ago from the Anaconda website and doing a "clean install"!
What a fiasco!
Until that point, NOTHING really worked. Almost every important command within Anaconda would fail with the Win32com error, and Navigator would not even start. Apparently the latest version of pywin32 is 304, but it doesn't work either. Is anyone looking into this? For a newbie like me, this is a very bad look for Anaconda as a tool! I was on the brink of simply giving up when I literally stumbled onto this thread.
Note that it has been MONTHS between my post and the one before mine. I'd say that this has probably caused a lot of people to simply give up (assuming that there are many who actually try to install this on Windows per month, that is).
I've had similar in the past,was about to give up on Anaconda.
Here's the solution
Apparently the wrong version of pywin32 gets installed.
I had the installed version 301 and after downgrading to 228 with pip install --upgrade pywin32==228 everything just started working.
Try pip install --upgrade pywin32==228
This should resolve the issue
Version 300 of pywin32 solved this issue for me! Check this other question for more info
Had the same issue with Conda and librosa in Python 3.9.
Librosa references from win32com.shell import shellcon,shell, which was causing the same error you received.
Installing pywin32 via conda fixed the error for me:
conda install -c conda-forge librosa
I ran into this issue when trying to get Anaconda to run at all on a new installation. I followed Alex T's recommendation to install version 300 of pywin32. Like him, I had to run it twice because it first installed version 302 for some reason. After running it the second time I can now run conda commands in that environment
pip install pywin32==300
My simple solution is to install an Older version of Anaconda. This worked perfectly for me. I installed Anaconda3-2021.11-Windows-x86 version.
The Newer Version of Anaconda has some problems with pywin32. I first tried the command :
pip install --upgrade pywin32==228
but It didn't workd for me. Installing an older version finally solved the problem of anaconda navigator not launching.
I am facing a situation where modules like pyodbc which used to work earlier (3 weeks back) are not working anymore in my laptop. I am repeatedly getting Module not found error.
To resolve it by myself, I have gone through similar articles in stack overflow and implemented some suggestions like this. Yet the issue still persists. My machine (Windows 10) has only one python version (python v3.7.2), and I have never created any virtualenv.
C:\Users\Kris\eclipse-workspace\SQLPyODBC>conntest.py --serverName "IDEA-PC\SQLEXPRESS" --name "SampleStore" --trustedConn "yes"
Traceback (most recent call last):
File "C:\Users\Kris\eclipse-workspace\SQLPyODBC\conntest.py", line 1, in <module>
import pyodbc
ModuleNotFoundError: No module named 'pyodbc'
The referenced package is available under C:\Users\Kris\AppData\Local\Programs\Python\Python37-32\Lib\site-packages directory. Also the path of python interpreter in eclipse IDE (PyDev) is pointing to correct python executable path.
Just to test, I have downloaded pymssql module, and guess what... it is also showing the same error message. I have uninstalled and re-installed packages. No solution.
If you're using Anaconda install using following code,
conda install -c anaconda pyodbc
Before importing pyodbc in python, you should install the module by using pip directly from cmd.
pip install pyodbc
if that does not work, try using pip to uninstall and install it again after a restart (Or kill all python related tasks). Hope it works
I'm trying to install NUMBA on a mac machine (10.12.6).
I've tried with CONDA:
conda install numba
I'm getting this:
Fetching package metadata ...........
Solving package specifications: .
# All requested packages already installed.
# packages in environment at /Users/lefaa/miniconda2:
#numba 0.35.0 np113py27_6
This seems good, however when I try (using python 2.7):
python -c "from numba import jit"
I'm getting that the numba module isn't installed:
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: No module named numba
Do I have to configure something else?
It is likely that your path is not set up correctly and the python that conda installed numba into is not the one you are running. If you run which python you should get the one that's in your miniconda2 if everything is working properly. If you get a different python executable then you probably need to set your PATH environment variable. See:
https://conda.io/docs/user-guide/install/index.html#installing-conda-on-a-system-that-has-other-python-installations-or-packages
I solved the issue. Indeed, when installing with conda, conda installs the target package in python associated to conda (i.e, in this python '/Users/lefaa/miniconda2/bin/python'). So to import numba, it is necessary to lunch the python of miniconda.
However, to install numba on the main python (python2.7), one solution will be to install like this '/usr/local/bin/pip2.7 install numba'.
I recently upgraded to OSX Sierra, and now I can't import any packages in Python. When I run a standard import numpy in the python console (I'm using Pycharm) I get
Traceback (most recent call last):
File "<input>", line 1, in <module>
File "/Applications/PyCharm CE.app/Contents/helpers/pydev/pydev_import_hook.py", line 21, in do_import
module = self._system_import(name, *args, **kwargs)
ImportError: No module named numpy
I think the problem's coming from when I reinstalled my ports when I was migrating macports, according to the instructions here. I'm pretty sure everything was working in python after I'd upgraded to Sierra, but broke once I did this.
My first thought was to reinstall numpy, but when I go to the command line and run pip install numpy, I get
Requirement already satisfied: numpy in /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python.
However, running which numpy turns up nothing, which seems weird, since it just told me that numpy's installed, and I can find it on my computer if I use easyfind. Since it might be relevant, which python gives me /opt/local/bin/python.
I've tried a few different fixes, but haven't been able to get anything to work so far. I have a feeling that I'm missing something very basic, but can't figure out what it is. I'm running python 2.7.12 on mac 10.12.1.
In my PyCharm I use virtual environments. An upgrade to Sierra may have, as you suggested, removed the Python port and thus your virtual environment may need to be recreated too.
Not exactly solving the original problem, but I did figure out how to work around it. I just installed python 3.3 (via macports) and set it to be the default python of my computer, and then reinstalled Pycharm (although I probably could have just restored settings to their defaults). Everything seems to be working now, in python 3.3, although I do have to use pip as python3.3 -m pip install rather than the standard pip install.
I am new to stackoverflow as well as Python, and I hope to use stackoverflow to learn and improve my Python programming.
However, as soon as I set up Python, SciPy, NumPy on my Mac, I encountered a problem when I tried running a full test of SciPy and NumPy to verify the install:
>>> import scipy
>>> scipy.test()
Running unit tests for scipy
Traceback (most recent call last):
File "<pyshell#4>", line 1, in <module>
scipy.test()
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/nosetester.py", line 318, in test
self._show_system_info()
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/nosetester.py", line 187, in _show_system_info
nose = import_nose()
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/nosetester.py", line 69, in import_nose
raise ImportError(msg)
ImportError: Need nose >= 0.10.0 for tests - see http://somethingaboutorange.com/mrl/projects/nose
As suggested by the error message, I install this 'nose' package via easy_install, and the install seems successful as I get the following from bash:
mlstr:~ mlstr$ nosetests -V
nosetests version 1.1.2
So I tried the SciPy test again, and it failed with the same message. Can someone please let me know if I need to do anything else to install/configure nose so that it can be used by the unit tests of SciPy and NumPy. Thanks in advance.
UPDATE #1: After trying Rahul's suggestion of using pip to reinstall nose, I think I've found where the problem is: whenever I do easy_install or pip from bash, the package is installed into Python 2.6 directories instead of 2.7 ones. And I think this is because by default 2.6 is the one shipped with Snow Leopard. So what should I do to tell easy_install or pip that I want to install a particular package for Python 2.7? Thanks.
UPDATE #2: By following up my update above, I've found the solution here: easy_install with various versions of python installed, mac osx. It is indeed because that I used the wrong version of easy_install thus my nose installation was for Python 2.6 shipped with Mac OS X. Thanks.
I tried replicating the error that you were encountering. I did not have nose, so I was getting the same error.
I installed nose using pip
sudo pip install nose
After that the scipy.test() worked. I did nothing else. Did you install nose using pip? If not, try using pip.
My machine has :
SciPy version 0.10.0.dev
Nose - 1.1.2
If you want to use your locally installed python version you need to make sure, that this is called when you run python from console.
On a linux machine an alias would do that. Once you run the correct python from your console all the easy_install things will be available in the correct python version.