I was trying to install ggplot using pip install ggplot. As it turned out, I was missing many essential packages, like stated in SciPy and blas and in SciPy with pip. After running
sudo apt-get install build-essential gfortran libatlas-base-dev python-pip python-dev I didn't get these "Cannot build wheel" errors anymore, luckily.
Now as I am trying just pip install scipy (which I need apparently) it fetches the package informations and gets stuck at Running setup.py install for scipy ... /. I can't imagine it takes this long time to install a 12 MB package (I waited for 30 minutes). Pip won't list it, so it's not isntalled. Does it really take so long? Or do I have another problem here, now? What am I missing?
I am running python3.4 on Ubuntu 14.04.
EDIT:
When trying pip install ggplot it gets stuck at the setup.py install for scipy too...
EDIT2:
It seems installing the package scipy for python3 did the trick. It is just completely unclear, why I need so many different packages from different sources to just get it to run. Anyhoo, scipy works and ggplot as well.
Scipy is compiling a lot of stuff. Depending on your computer it might take some time.
try:
pip -v install scipy
pip -vv install scipy
pip -vvv install scipy
(more and more verbose logging output)
Related
When I try to install scipy for 3.4 it throws this error when I run this command:
sudo pip3.4 install scipy
https://www.pastiebin.com/5a7c65d7e44fe
I was able to get it to install with Python 3.6 but not 3.4.. which I need.
Installing Scipy or Numpy from scratch is usually hard work. At best try a distribution that already has it installed (WinPython, Anaconda). If you are on Linux install the packages that come with your distro. On Windows you can also grab the wheels at Gohlke.
I'm using JetBrains PyCharm Community Edition 2016.3.2 (64). My Project Interpreter is either Python 3.4 or 3.5. I'm trying to install the Matplotlib package but failed every time. I succeeded on installing Networkx though.
On this site https://networkx.github.io/documentation/networkx-1.10/tutorial/tutorial.html, in the "Drawing graphs" section, it says
Note that the drawing package in NetworkX is not yet compatible with Python versions 3.0 and above.
Someone please confirm this? Should I install Python 2.x to use this package?
I'm doing graph modelling, if anyone can suggest other packages or advise whatever I should use, I would really appreciate. But it needs to be related to Networkx.
Regarding Matplotlib, I don't see why the installation would fail.
try:
sudo apt-get install python3-matplotlib
Depending on your installation, you'll also have to install several libraries that matplotlib depends on:
sudo apt-get install python3.5-dev python3.5-tk tk-dev
sudo apt-get install libfreetype6-dev g++
sudo apt install python3-pip
pip3 install --user matplotlib
In addition, you will need one other package - nose. You can install it using the same syntax:
sudo pip3 install nose
Networkx installation is simple as:
sudo pip3 install networkx
Good luck!
Environment is Python 3.5 and CentOS 7.0 in VPS (XEN).
I use IUS repository for CentOS7 to install Python 3.5 and corresponding devel, setuptools packages.
Then upgrade pip3.5 itself by
sudo pip3.5 install upgrade pip
Numpy and Matplotlib can be installed by pip 3.5 without any problem.
sudo pip3.5 install numpy
sudo pip3.5 install matplotlib
But when I try to install scipy, it got stuck at the step running setup.py like forever. Only way to get rid of this is Ctrl+C. Tried several times, even reinstall CentOS and compile Python3.5 from source code. Always the same issue happens.
Collecting scipy
Using cached scipy-0.17.0.tar.gz
Installing collected packages: scipy
Running setup.py install for scipy ... \
Could someone help me out please?
update (Feb 9th 2016):
A 1.5GB swapfile is created manually, which is none originally. Then after about 2 hours waiting, it is finally installed. I guess the relatively low performance of server leads to this problem.
Many python packages have build dependencies on non-Python packages. I'm specifically thinking of lxml and cffi, but this dilemma applies to a lot of packages on PyPI. Both of these packages have unadvertised build dependencies on non-Python packages like libxml2-dev, libxslt-dev, zlib1g-dev, and libffi-dev. The websites for lxml and cffi declare some of these dependencies, but it appears that there is no way to do figure this out from a command line.
As a result, there are hundreds of questions on SO that take this general form:
pip install foo fails with an error: "fatal error: bar.h: No such file or directory". How do I fix it?
Is this a misuse of pip or is this how it is intended to work? Is there a sane way to know what build dependencies to install before running pip? My current approach is:
I want to install a package called foo.
pip install foo
foo has a dependency on a Python package bar.
If bar build fails, then look at error message and guess/google what non-Python dependency I need to install.
sudo apt-get install libbaz-dev
sudo pip install bar
Repeat until bar succeeds.
sudo pip uninstall foo
Repeat entire process until no error messages.
Step #4 is particularly annoying. Apparently pip (version 1.5.4) installs the requested package first, before any dependencies. So if any dependencies fail, you can't just ask pip to install it again, because it thinks its already installed. There's also no option to install just the dependencies, so you must uninstall the package and then reinstall it.
Is there some more intelligent process for using pip?
This is actually a comment about the answer suggesting using apt-get but I don't have enough reputation points to leave one.
If you use virtualenv a lot, then installing the python-packages through apt-get can become a pain, as you can get mysterious errors when the python packages installed system-wide and the python packages installed in your virtualenv try to interact with each other. One thing that I have found that does help is to use the build-dep feature. To build the matplotlib dependencies, for example:
sudo apt-get build-dep python-matplotlib
And then activate your virtual environment and do pip install matplotlib. It will still go through the build process but many of the dependencies will be taken care of for you.
This is sort what the cran repositories suggest when installing R packages in ubuntu.
For most popular packages, There is a workaround for recent ubuntu systems. For example, I want to install matplotlib. When you order pip install matplotlib, it usually fails because of a missing dependency.
You can use apt-get install python-matplotlib instead. For python3, you can use apt-get install python3-matplotlib
I'm trying to upgrade Scipy from 0.9.0 to 0.12.0. I use the command:
sudo pip install --upgrade scipy
and I get all sorts of errors which can be seen in the pip.log file here and I'm unfortunately not python-savvy enough to understand what's wrong. Any help will be appreciated.
The error messages all state the same: You lack BLAS (Basic Linear Algebra Subroutines) on your system, or scipy cannot find it. When installing packages from source in ubuntu, as you are effectively trying to do with pip, one of the easiest ways to make sure dependencies are in place is by the command
$ sudo apt-get build-dep python-scipy
which will install all packages needed to build the package python-scipy. You may in some cases run into the problem that the version of the source package you are trying to install have different dependencies than the version included with ubuntu, but in your case, I think chances are good that the above command will be sufficient to fetch BLAS for you, headers included.
I had the same problem upgrading from scipy 0.9 to 0.13.3, and I solved it using the following answer and installing:
sudo apt-get install libblas-dev
sudo apt-get install liblapack-dev
sudo apt-get install gfortran
Make sure libatlas-base-dev and libatlas-sse2-dev are installed, it seems like it can't find your atlas library. Also, see this question:
Does Python SciPy need BLAS?
I found Adam Klein's instructions for setting up scipy (and friends) in a virtual environment very useful.
One problem I ran into (which was probably my own fault): After all was said and done, I found importing scipy still loaded version 0.9.0, not 0.12.0. The problem was that my sys.path was finding the old system version before the new version.
The fix was to make
/path/to/.virtualenvs/arthur/local/lib/python2.7/site-packages
appear before
/usr/lib/python2.7/dist-packages
in sys.path. If you have virtualenvwrapper installed, then
you can add the path using
add2virtualenv /path/to/.virtualenvs/arthur/lib/python2.7/site-packages