I just got access to a new server which has Python 2.7 and some packages already installed. However, I need the newest version of scikit-learn (0.18.0).
I tried to pip-upgrade the package, which returns the following affirmative message Successfully installed scikit-learn Cleaning up...
I used the following command, which worked for upgrading other packages (e.g. scipy):
OPENBLAS=/cluster/apps/openblas/0.2.13_seq/x86_64/gcc_5.2.0/lib python -m pip install --user --upgrade scikit-learn
When checking the version with pip freeze and python -c 'import sklearn; print sklearn.__version__' it continues to show the old version (0.17.1). In my home directory (I don't have root access) a folder named 'scikit_learn-0.18-py2.7.egg-info' was created.
Can someone point out what I'm doing wrong?
Edit: I'm on Centos 6 and packages like numpy and scipy worked just fine
Hi I was in the same situation as you, in order to get the correct version of sklearn, before importing it,
I added this line to my code:
import sys
sys.path.insert(0, '/home/your_user_name/.local/lib/python2.7/site-packages/')
I am not quite sure about the path part, but basically I think it is
sys.path.insert(0, '$HOME/.local/lib/python2.7/site-packages/')
Hope this helps.
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
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!
I was just given a new mac and after installing pip and lcc through pip I get a command not found error when running lcc run.
When running help("modules") inside of python I can see the lcc package there.
the same goes for pip freeze
pip freeze | grep lemon
lemoncheesecake==0.15.2
I'm running out of ideas.....
maybe I messed up the pip installation because I did it first with:
python get-pip.py
and then with
sudo easy_install pip
how do I fix this?
this is my echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
Thanks
From what you're saying it seems that your python installation is not quite right, and Mac's version of python is also not quite right by default, you can read more about it here: http://docs.python-guide.org/en/latest/starting/install/osx/#doing-it-right
Also, I would highly advise that when you get a brand new Mac and plan to do some development work as a rule of thumb follow these steps:
Install xcode
Install Homebrew
Then you can install anything else you want.
I think the problem is due to the fact you have more than one version of python installed. Package installed by pip are visible to one version, but not to the other. I think this issue is quite common, and has already been answered (for example) here:
Too many different Python versions on my system and causing problems
To check that this is the case:
pip show Icc
should tell you where Icc was installed.
import sys
print sys.path
should tell where python looks for modules.
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.
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.