I have a machine with Python 2.6 installed as the default Python. Then, I installed Python 2.7, and manually created /usr/bin/python as a symlink to the new installation.

Then, I was running into problems with command-not-found. I'm trying to reinstall it:

sudo apt-get remove command-not-found

and I get this error:

/usr/bin/python does not match the
python default version. It must be
reset to point to python2.6

But I really want Python 2.7 to be the default. How do I fix this mess?


5 Answers 5


Changing the default Python (or Perl, etc) on an OS is really bad idea. This interpreter is actually part of the OS and there may well be other OS components that are written specifically to work with that version of the interpreter.

For example on Redhat the yum tool that performs system software updates is a python application. You really don't want to break this. Such applications may depend on specific, perhaps non standard, python modules being installed which the version you installed may not have. For example on Ubuntu I believe some of the built-in OS tools written in Python use an ORM called Storm that isn't part of the Python standard library. Does your clean Python 2.7 install have the specific expected version of the Storm module installed? Does it have any version of Storm? No? Then you've just broken a chunk of your OS.

The right way to do this is install your preferred version of python and set up your user account to use it by setting up your .bash_profile, path and such. You might also want to look into the virtualenv module for Python.

  • 1
    Googled my way here. Would -1 if I had the rep on this stack. Why? Because the suggested approach says only "install your preferred version of python". How is that done without hosing the system python?
    – jez
    Commented Dec 16, 2015 at 21:45
  • 1
    @jez Users should refer to the installation instructions for their application and OS combination of choice. In general language installer packages will install to a benign location, not overwrite core OS components so overwriting the OS version would be the special case. Commented Aug 26, 2016 at 12:04



Pyenv allows you to manage multiple Python versions without sudo for a single user, much like Node.js NVM and Ruby RVM.

Install Pyenv:

curl https://pyenv.run | bash

Then add to your .bashrc:

export PATH="${HOME}/.pyenv/bin:$PATH"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"

Find Python version to install:

pyenv install --list

Install the python version you want:

# Increase the chances that the build will have all dependencies.
# https://github.com/pyenv/pyenv/wiki/Common-build-problems
sudo apt build-dep python3
sudo apt-get install -y make build-essential libssl-dev zlib1g-dev libbz2-dev \
  libreadline-dev libsqlite3-dev wget curl llvm libncurses5-dev libncursesw5-dev \
  xz-utils tk-dev libffi-dev liblzma-dev python-openssl git

# Build and install a Python version from source.
pyenv install 3.8.0

List available Python versions:

pyenv versions

We now have:

* system (set by /home/cirsan01/.pyenv/version)

Select a different python version:

pyenv global 3.8.0
python --version
python3 --version

Both output:

Python 3.8.0

We can now proceed to install and use packages normally:

pip install cowsay
python -c 'import cowsay; cowsay.tux("Python is fun")'
cowsay 'hello'

We can confirm that everything is locally installed in our clean environemnt with:

python -c 'import cowsay; print(cowsay.__file__)'
which cowsay

Per project usage

In the previous section, we saw how to use pyenv in a global setup.

However, what you usually want is to set a specific python and package version on a per-project basis. This is how to do it.

First install your desired Python version as before.

Then, from inside your project directory, set the desired python version with:

pyenv local 3.8.0

which creates a file .python-version containing the version string.

And now let's install a package locally just for our project: TODO: there is no nice way it seems: https://stackoverflow.com/questions/30407446/pyenv-choose-virtualenv-directory/59267972#59267972

Now, when someone wants to use your project, they will do:

pyenv local

which sets the Python version to the correct one.

Related threads:

Tested on Ubuntu 18.04, pyenv 1.2.15.

  • There are many articles on the web which recommend using update-alternatives to switch between multiple installed versions of Python. However I don't think this is a good idea because if I understand correctly this will also change the default Python interpreter version which is visible to the whole system, and therefore might break some OS dependencies. Are my thoughts on that correct? More generally - why is using pyenv a better solution? Commented Apr 11 at 8:38
  • @user3728501 yes, changing your system wide python will blow things up. Ubuntu doesn't even allow you to pip insatll globally anymore for example. Commented Apr 11 at 8:41
  • 1
    So using update-alternatives is a bad idea, right? Commented Apr 11 at 8:44
  • @user3728501 yes, bad idea Commented Apr 11 at 8:52

How do I fix this mess?

Nothing more than reinstalling python. It will undo your change (the symlink).

Why do you want it as default? Each time you need it, just use python2.7 or include #!/usr/bin/python2.7 (the shebang) at the beginning of your (executable) scripts.

If you insist on having python2.7 as system-wide default, use a later release of Ubuntu (currently it's Ubuntu 11.04, codenamed Natty). It uses that version as default.

In future, avoid doing manual interventions like what you did with the symlink thing. This is especially true for distro-managed files, and most especially for complex beasts like Python installations.

  • 2
    @ripper: I guess I'm coming to this thread a little late. As Tshepang says the python package on Ubuntu determines the system version. Now, it is possible to customize your installation so python 2.7 is default by creating your own python package etc, but if so, you'll effectively be becoming maintainer of your Python installation instead of Ubuntu, and you'll have to learn how Python is managed on Debian/Ubuntu. Bear in mind that the other Python packages in the system are configured to work with 2.6 as default, so, apart from anything else, breakage may result. Commented Mar 20, 2011 at 8:56
  • 1
    @Tshepang: Good summary! Commented Mar 20, 2011 at 9:23
  • 14
    @ripper234: Don't change anything in /usr/bin, that's reserved for your distribution. Instead, make /usr/local/bin/python a symbolic link to python2.7. Then scripts using #!/usr/bin/env python (the recommended idiom), as well as typing python on the command line, will run Python 2.7. Scripts from the distribution that want the Python from the distribution can keep calling #!/usr/bin/python. Commented Mar 20, 2011 at 13:22
  • 1
    @Gilles: I've found at least one distro-provided package that uses #!/usr/bin/env python. So, I wouldn't recommend this.
    – tshepang
    Commented Mar 20, 2011 at 13:55
  • 1
    @Tshepang: Most distro-provided packages won't mind a more recent version, so it's ok for them to be executed with your own, more recent Python. Commented Mar 20, 2011 at 14:00

i just posted this same answer to stack overflow:


(see that one for a more up-to-date answer)

Here is my take on the problem. Works for Python3. The main features are:

  • Each Python version is compiled from source
  • All versions are installed locally
  • Does not mangle your system's default Python installation in any way
  • Each Python version is isolated with virtualenv

The steps are as follows:

  1. If you have several extra python versions installed in some other way, get rid of them, e.g., remove $HOME/.local/lib/python3.x, etc. (also the globally installed ones). Don't touch your system's default python3 version though.

  2. Download source for different python versions under the following directory structure:

        python_versions/ : download Python-*.tgz packages here and "tar xvf" them.  You'll get directories like this:
  3. At each "Python-3.x.y/" directory, do the following (do NOT use "sudo" in any of the steps!):

    mkdir root
    ./configure --prefix=$PWD/root 
    make -j 2
    make install
    virtualenv --no-site-packages -p root/bin/python3.x env
  4. At "python_versions/" create files like this:

    echo "type deactivate to exit"
    source $HOME/python_versions/Python-3.x.y/env/bin/activate
  5. Now, anytime you wish to opt for python3.x, do

    source $HOME/python_versions/env_python3x.bash

    to enter the virtualenv

  6. While in the virtualenv, install your favorite python packages with

    pip install --upgrade package_name
  7. To exit the virtualenv and python version just type "deactivate"

  • --no-site-packages does not work with virtualenv in Ubuntu 20.04 (20.0.17). See this note: stackoverflow.com/a/60783839/286807 Commented May 7, 2020 at 23:29
  • I updated my answer in the stack overflow version. Please check it out & upvote if you like the solution.
    – El Sampsa
    Commented May 10, 2020 at 19:50

We put multiple python distributions on Mac and Ubuntu a lot and here are my recommendation.

  1. Leave the system python unmolested: never use it.

  2. If you only need one primary python distribution, download and install Canopy from enthought. When it installs, choose "set as my system python", and then you can install packages from Canopy's GUI package manager.

    • Canopy is also compaitble out of the box with pip, the PyPi package manager command that lets you install packages (eg pip install python-twitter)
  3. If you plan to use virtual environments (ie you are developing python programs and want a dedicated clean python environment for each, with an easy means to switch between them), I'd recommend Anaconda over Canopy due for it's virtual environment manager tool. This will let you

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .