I am trying to run a program using paster serve, but I keep getting the error:
ImportError: No module named dateutil.relativedelta
I am running Python version 2.6.7 and dateutil version 1.5, so it should be installed.
Has anyone got any ideas as to why this would happen?
I am importing using
from dateutil.relativedelta import *
I can even see the package when I search:
/usr/lib/python2.7/site-packages/dateutil/relativedelta.pyc
/usr/lib/python2.7/site-packages/dateutil/relativedelta.py
/usr/lib/python2.7/site-packages/dateutil/relativedelta.pyo
UPDATE
Immediately I look at this and see that dateutil is only installed for Python 2.7, and I bet what I was doing was this:
sudo yum install python-dateutil
To which sudo would have switch to the default Python version (i.e., Python 2.7 instead of 2.6.4).
Solving this would have been as simple as:
su
(switch to virtual environment)
yum install python-dateutil
Using su and then switching to the virtual environment will give root access and install to the virtual Python directory. Using sudo will install libraries to the default directory, not the virtual environments site-packages.
I also ran into this issue. The simple solution I ended up using was to add --upgrade to the end of the command. This forced it to install it even though Python thought it was installed. This resolved the issue.
So if you have this issue, try the following:
sudo pip install python-dateutil --upgrade
It can't possibly hurt anything, so there is no harm in just forcing it to be reinstalled.
I had a similar issue but for a simpler reason. My fresh virtualenv simply didn't have dateutil installed and I didn't know the Python package name. I tried pip install dateutil, which obviously didn't work since the package name was incorrect. Running pip install python-dateutil instead worked (without resorting to sudo).
This looks like a problem of package installation to me. A troubleshooting list that comes to my mind:
Verify you installed the package.
If installed, verify that the files have been stored in the right directory (a directory accessible from your python interpreter (= in the PYTHONPATH, useful article here).
Verify permission on those files.
Restart your shell if you tried the import there.
Reboot your computer (ouch... it's 10 years since I started using GNU/Linux, but I still suffer from the bad memories of Windows! ;)
(The previous comment about installing python-dateutil helped me, so perhaps my comment helps someone else).
For those on Mac OS (v10.6 (Snow Leopard); I am not sure about other versions), the dateutils package is located by default at:
/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/dateutil
whereas pip install writes the package out to:
/Library/Python/2.6/site-packages
and does not update the /Library/Python/2.6/site-packages/easy-install.pth file. As a result, when you import dateutil, you will still point to the old location, you can verify this by "import dateutil; dateutil.__file__".
So what I did (probably better methods are available) was to rename the old directory (/System/Library/.../dateutil) to dateutil.obsolete and restarted Python, then ran the same set of commands again. This doesn't do anything to the path file or sys.path, but skips the old dateutils package so you can get to the new one.
Related
I have installed Cassandra database on my CentOs system. after that, I tried to install the Cqlsh package using this command sudo yum install cqlsh and it has been installed successfully. but when I tried to run cqlsh from the terminal, the following error appears:
ImportError: cannot import name ensure_str
somewhere in the code, it tries to load a library named six that contains ensure_str. the error does not say that it can not find a module named six, the python interpreter can find the library but can not import it!
I have tried googling but none of the solutions worked for me.
after a few hours of googling and struggling with the code, finally, I find out the solution. and I'm going to share it with others.
apparently, the problem is the new version of six (v=1.7.3) which is not compatible with my system. However, Cassandra copies the last version of six into the following path:
/usr/share/cassandra/lib/six-1.7.3-py2.py3-none-any.zip
then cqlsh try to force the python interpreter to import the library from this path by adding the following lines to the code.
third_parties = ('futures-', 'six-', 'geomet-')
for lib in third_parties:
lib_zip = find_zip(lib)
if lib_zip:
sys.path.insert(0, lib_zip)
no matter if you have another version of six installed on your system, it always tries to import the library from the Cassandra folder.
So, I have just deleted these lines from cqlsh file using this command:
vim /usr/bin/cqlsh
Then I try to install the last compatible version on six using this command:
yum install six
That's it! problem solved and now I'm using cqlsh without any problem.
I hope it helps others.
We've had reports of this being a problem on CentOS specifically with version 6.7 but it possibly affects the 7.x releases too.
It appears that the wrong Python is getting called. This isn't strictly a Cassandra issue but a problem with the Python on the machine. You can verify which Python gets run with:
$ which python
As a workaround, you should be able to run cqlsh using the system Python as follows:
$ /usr/local/bin/python /usr/bin/cqlsh
Cheers!
Use pip3 to install or upgrade to the current six.
Edit a copy of cqlsh. Change
third_parties = ('futures-', 'six-', 'geomet-')
to
third_parties = ('futures-', 'geomet-')
Not proud, but it worked.
Used pip3 to install, and found this issue as well.
For me, removing six dependencies from /usr/lib/python3/dist-packages was the only thing that worked.
rm six-1.11.0.egg-info and rm -r six-1.11.0.egg-info
I couldn't uninstall it with pip3, so manual removal was the way to go, followed by a pip3 install six
Once that was back in place, cqlsh ran without issue.
The previous answers didn't work for me, I had to delete the Cassandra included six package, and then cqlsh used the system-wide package.
mv /usr/share/cassandra/lib/six-1.7.3-py2.py3-none-any.zip /usr/share/cassandra/lib/six-1.7.3-py2.py3-none-any.zip.bak
Maybe an older version of Cassandra installed, and a newer version of cqlsh?
https://community.datastax.com/questions/12085/unable-to-connect-to-cqlsh.html
This is probably a really dumb question but I am stuck and wasting too much time on this so I would SO appreciate any help.
I am using a RHEL 7 box and installed Apache Zeppelin on it. Everything works except for the life of me I can't import Python packages such as Pandas.
I realized I didn't have PIP so I installed it with these steps: https://pip.pypa.io/en/stable/installing/ (notice I had to use the "--user" argument for the command "python get-pip.py").
Finally, I did "pip install pandas --user" which worked perfectly. I then go into my Zeppelin notebook and I cannot import pandas, even after restarting the Python interpreter.
I did some research and I think the problem is that "which python" and "which pip" are installed in different directories as the former results in "/usr/bin/python" while the latter in "~/.local/bin/pip".
So I suspect the packages installed with pip are basically getting loaded into a different version of python? If it helps, when I do "whereis python" I get 5 different results such as "/usr/bin/python" and "/usr/bin/python2.7" etc.
First thing to understand is: Python packages aren't installed globally, every installed Python has its own set of packages. BTW, pip being a Python package with a script is also not global. If you have a few different pythons you need different pips for them. I don't know Apache Zeppelin so I cannot guess if it uses the system Python (/usr/bin/python) or has its own Python; in the latter case you need to install pip specifically for Zeppelin so its pip install packages available for Zeppelin.
To investigate to what Python pip installs packages you need to find out under what python it runs. Start with shebang:
head -1 `which pip`
The command will prints something like ~/.local/bin/python. If it's not the version of Python you need to install packages for you need to install a different pip using that Python.
The most complex case would be if the shebang is PATH-dependent, something like #!/usr/bin/env python. In that case pip runs Python that you can find with which python.
PS. AFAIK the simplest way to install pip at RedHat is dnf install python-pip.
phd's answer was very helpful but I found that it was just a matter of using the root account to install the python packages. Then my Zeppelin was able to see any packages.
I've been trying to install astropy and at the end of the installation I get this message:
Cannot uninstall 'numpy'. It is a distutils installed project and thus
we cannot accurately determine which files belong to it which would
lead to only a partial uninstall.
I have tried: pip uninstall numpy and then I get the same message.
I have Python 2.7.10 in a macOS High Sierra version 13.10.5
This doesn't directly answer your question, but that's because you're asking the wrong question.
Astropy requires Python 3.5 or 3.6. Trying to get it working with Apple's pre-installed Python 2.7 is a waste of time. You might be able to get an old version working this way, but not by using the installation instructions on astropy.org, and it won't be supported even if you do.
The easy solution is to just Install the latest Anaconda 5.x with Python 3.6, because it comes with Astropy built in.
The almost-as-easy solution is to install Python 3.6 from either a python.org binary installer, or Homebrew, and then use pip3 or, better, python3 -m pip to install everything, as explained on the Astropy install page.
Either way, before doing anything else, you want to get back to a clean slate. In particular, you do not want pip, or any other scripts, attached to Apple's Python 2.7; they will only cause confusion. Assuming you can't reinstall macOS from scratch, the best way to do this is:
Look in /Library/Python/2.7/site-packages and delete everything there except for README and Extras.pth.
Look in /usr/local/bin for symlinks to anything in that site-packages. (If you don't know much about using Unix, try this command: ls -l /usr/local/bin | grep 2.7.) You'll probably have pip and pip2.7 here, and probably nothing else. But whatever you have here, delete it.
Now, when you install Python 3.6, the only thing named pip anywhere will be that Python 3.6's pip. You still want to use pip3 or python3 -m pip, but if you screw up and type pip by accident, it won't break anything.
Also, you should strongly consider using a virtual environment. See the Python Packaging Authority's User Guide (or the Anaconda docs, if you went that way) for more on this.
One simple solution I found:
sudo -H pip install astropy --ignore-installed numpy
I also had this issue and couldn't get around it in a clean way, but this is what I did:
Inside the Lib folder search "numpy" for an egg_info file (eg. numpy-1.11.0.dev0_2329eae.egg-info).
In my case, this is what Pip was looking at to determine if a current version already exists. I deleted it, then ran normal
pip install numpy
and installed the newest version.
I don't recommend this because I don't understand what it's doing under the hood and it doesn't properly uninstall the old version which could be a recipe for trouble down the line, but if you're desperate like I was then maybe this is a solution for you.
I try a python code for signature recognition, and there is an import ffnet module (from ffnet import mlgraph, ffnet), but I got an error when I run it.
The error is:
ModuleNotFoundError: No module named 'ffnet'
I have install the module, but still got that error
Help me to fix this :)
You need to make sure that it is correctly installed. The error message means directly "You haven't installed it properly".
Depending on what Python version you're using, you should have a package manager called pip that takes charge of installing and uninstalling modules. Try:
pip2 install ffnet if you have Python 2.
pip3 install ffnet if you have Python 3.
Alternatively, you may have installed Python using Anaconda. In this case, use conda install ffnet. In all cases, run the proposed commands in a terminal.
However, it would be quite useful to have more details about your problem (what OS do you have, how and where did you install Python, what version do you have).
There is great chance that the pip (i suppose you use pip for installation, the idea is identical) you use to install ffnet is not correspond to the python you are using. Maybe a virtualenv is running, or you using python 2 but ffnet is installed with pip3
My suggestion:
- Run which pip. Run which python. Compare the results if anything seem wrong (python2 pip3 for example). Try to run python2 and pip2 instead of python and pip
- If the above suggestion doesn't work, you should try to recheck your PATH: Find the pip correspond to your current python (usually within the same dir) and export PATH=/path/to/THAT/pip/:$PATH
- If the problem still persist, I suppose your pip file's first line (for specifying its corresponding python path) has been modified without your awareness. You will have to manually edit it to something like #!/usr/bin/python3
Hope this help!
Need help updating a python package.
I have an implementation that requires the following import
from twisted.internet.ssl import optionsForClientTLS
"optionsForClientTLS" was added to the twisted framework with version 14(?). I think the non-virtualenv import is getting a dated version-- If that import is within a virtualenv that has twisted installed via pip, everything is fine. Import fails outside the virtualenv.
In the virtualenv
twistd --version
Shows 15.2.1. On the bare system it shows 13.2.0.
pip install twisted
....
pip freeze
shows
Twisted==15.2.1
Uninstalling twisted using pip and reinstalling didn't help. You can install twisted from apt-get using
sudo apt-get install python-twisted
and it installs the older version, but after purging it and installing using only pip I still get the older version.
Possibly related.
I solved the issue in a terrible way. It was a few days ago, so the paths may not be exactly right.
The assumption that there were two python packages was correct (I think.) I suspect the order of the paths in PYTHONPATH meant that the wrong version was being imported first, while pip was installing in a version that was later on in the path.
My "solution" was to copy the twisted directory from the up to date version to the older version. This was either from usr/local/lib/python... to usr/lib/python... or from ... site-packages to ... dist-packages. I can check again if someone has the same issue and can't resolve it.