Multiple versions of python when installing a package with aptitude

Question

On a lab machine where I can't just go clobbering things, there appears to be more than one version of python installed.

If I python --version I see 2.7.1.

I've installed numpy via "apt-get install numpy" and it says it is installed, but when I try to import it it isn't found.

When I do a find on the machine for numpy I see it in the /usr/lib/python2.5/site-packages/numpy folder. I assume this is the problem... that apt-get put it in the 2.5 version instead of the 2.7.

How do I resolve this? Is there a way to tell apt-get which python I'm talking about when I do an install? Or do I abandon aptitude and use pip or something?

Answer 1

Debian allows for multiple Pythons to be installed (the python2.5 and python2.6 packages). A Python library like numpy in the package python-numpy can support multiple of these, but particular libraries installed through the package manager are not necessarily supported on all of these. You can use apt-cache show python-numpy | grep Python-Version to see which versions are supported. If 2.7 is not supported, you'll have to install from source or (e.g.) pip, easy_install, etc.

However, you may have a local installation of Python 2.7 (compiled and installed from sources outside of the repos). Your distro sounds a little out of date (on Linux Mint 12, only 2.6 and 2.7 are supported for numpy), so it's possible there aren't official packages for Python 2.7. If you do which python and it's in /usr/local or anywhere other than /usr/bin, then you've got a local installation and you will need to install the package using source or easy_install and friends.

That said, my opinion is that if you just need these libs for development, you should keep them in a sandbox (like virtualenv) in your home directory. That way you have better control over the exact version you have.

Answer 2

If you want to use multiple versions of python on one machine, you should investigate virtualenv.

virtualenv is a tool to create isolated Python environments.

The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.7/site-packages (or whatever your platform's standard location is), it's easy to end up in a situation where you unintentionally upgrade an application that shouldn't be upgraded.

Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application.

Also, what if you can't install packages into the global site-packages directory? For instance, on a shared host.

In all these cases, virtualenv can help you. It creates an environment that has its own installation directories, that doesn't share libraries with other virtualenv environments (and optionally doesn't access the globally installed libraries either).

Here is a question with a similar solution.

In addition, I use virtualenvwrapper because I find it makes life a lot easier to manage multiple environments.

Answer 3

A good, standard and easy way to install python modules is pip

with this you install a package with command(in terminal not in python shell)

pip install <packagename>

(with root privileges)

It takes care of the dependencies.

Handling multiple versions of python:

I do not know if this is a standard practice or not but I do it this way.

To install a package on say version 2.5 I do,

python2.5 /usr/bin/pip install <packagename>

Ubuntu by default has multiple python versions available (e.g. 2.4, 2.6, 2.7, 3.2 etc)

In your case, if you do not wish to install numpy on python2.7 (you should IMO :)) and you are okay working with python2.5, you can use numpy by launching python2.5

    $python2.5

    >>> import numpy
    >>>

EDIT:

If you use apt-get install, the package will get installed on the system default python version.

Answer 4

Apt/dpkg have a Debian way of managing multiple installed versions of Python (I believe it is called python-support). Any extra package, like numpy, that you install will automatically be built and available for all the versions of Python supported by that package AND installed by dpkg. Since numpy supports every Python, your info tells me that the only Debian python package on your system is 2.5, and the 2.7 in your PATH is probably in /usr/local. When you install the numpy package it doesn't know about the locally built 2.7. You can always easy_install.

The suggestion to use virtualenv is a good one. I have a production system I support using python 2.5, which has been dropped from debian unstable; virtualenv makes it possible to work with whatever version you need. SInce python is needed by so many tools it's better leave system python at whatever Debian wants it to be.