Go to python3 dist-package directory

cd /usr/lib/python3/dist-packages

And then link these two files

sudo ln -s apt_inst.cpython-35m-x86_64-linux-gnu.so apt_inst.so
sudo ln -s apt_pkg.cpython-35m-x86_64-linux-gnu.so apt_pkg.so

Felix Krull runs a PPA offering basically any version of Python (seriously, there is 2.3.7 build for vivid...) for many Ubuntu releases at https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa.

Do the usual:

sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt-get update
sudo apt-get install python3.5

It will not overwrite your existing python3.4 which is still symlinked as python3.

Instead, to run python3.5, run the command python3.5 (or python3.X for any other version of python).

DON'T change the symlink! There are apparently many system functions that don't work properly with python3.5.

I tried this and afterwards couldn't open a terminal, software updater,...

cd /usr/bin
sudo rm python3

The upgrade to Wily will adapt the meta-package python3 to point to python3.5. I don't expect any breakage, but at this point the foreign repository is not needed anymore. So to be really safe, you can purge the PPA before doing the upgrade.

I will appreciate if someone could explain the differences (if any) between:

Highest level: you never should use pip install to install to system (--system, or on Linux distros where --user isn't the default, omitting --user) when things might conflict with your system whereas apt install is pretty safe.

Explanation:

apt is the package installation tool of your Linux distro. A Linux distribution these days is mostly the effort to offer a way to install packages in a way that works with each other without breaking – for example, if you're trying to install a library that libreoffice uses, but in a version incompatible with your libreoffice, your linux distro tool will tell you that sadly, to fulfill your command, it will have to uninstall libreoffice, because it wouldn't work with that version you're requesting.

The fact that you very rarely see that happen is an indication of how well modern Linux distros are doing here: typically, most of software that you can install using apt works well together.

pip, on the other hand, has no notion of what other software you have on your machine, which you might need. You tell pip to install something in a version that breaks your ability to even boot your system – it will go ahead and do that.

pip is python-specific. It assumes that all there is on that machine that has something to do with Python is kind of "fair game" and can be dealt with arbitrarily. Frankly, that is almost never the case – for example, on Fedora (another Linux distro that you're not using), you can easily break the installation tool dnf (Fedora's apt, if you will) with pip.

So, why does pip still exist? Well, there are situation where it's OK for pip to assume every bit of python it sees is under its control: Python brings a mechanism called virtual environments. In these, no python modules are per se installed, and they don't conflict with other software on your machine – simply because other software isn't aware of the environment.

Using that is quite straightforward. You can set up such an environment using

python3 -m venv ~/bertsexperiment

That sets up a folder ~/bertsexperiment for Python stuff to be installed into. You can then, from anywhere you like, "activate" that environment (what that really does is just change a few environment variables) – but that only affects the current process and things started from it. Try it:

source ~/bertsexperiment/bin/activate

will set up this shell in a way that all future python tooling will work with that folder as "prefix".

For example, if you wanted to have an updated setuptools in that shell, you could, after sourceing the activaton script as shown above, run pip3 install --upgrade setuptools, and they would be installed into the virtualenv.

In short:

• if in doubt, use apt, because it's your distro's job to keep your software stack working together
• Never use pip unless you intend to install something into a folder only used for your current project and not by anything else on your system.
  Hence, the only realistic time you would want to use it is when you're using a Python virtualenv.

It's recommended to use the apt module from the python-apt Debian package. This is a higher level wrapper around the underlying C/C++ libapt-xxx libraries and has a Pythonic interface.

Here's an example script which will install the libjs-yui-doc package:

#!/usr/bin/env python
# aptinstall.py

import apt
import sys

pkg_name = "libjs-yui-doc"

cache = apt.cache.Cache()
cache.update()
cache.open()

pkg = cache[pkg_name]
if pkg.is_installed:
    print "{pkg_name} already installed".format(pkg_name=pkg_name)
else:
    pkg.mark_install()

    try:
        cache.commit()
    except Exception, arg:
        print >> sys.stderr, "Sorry, package installation failed [{err}]".format(err=str(arg))

As with the use of apt-get, this must be run with superuser privileges to access and modify the APT cache.

$ sudo ./aptinstall.py

If you're attempting a package install as part of a larger script, it's probably a good idea to only raise to root privileges for the minimal time required.

You can find a small example in the /usr/share/pyshared/apt/progress/gtk2.py:_test() function showing how to install a package using a GTK front-end.

Ubuntu 12.10+ and Fedora 13+ have a package called python3-pip which will install pip-3.2 (or pip-3.3, pip-3.4 or pip3 for newer versions) without needing this jumping through hoops.

I came across this and fixed this without needing the likes of wget or virtualenvs (assuming Ubuntu 12.04):

1. Install package python3-setuptools: run sudo aptitude install python3-setuptools, this will give you the command easy_install3.
2. Install pip using Python 3's setuptools: run sudo easy_install3 pip, this will give you the command pip-3.2 like kev's solution.
3. Install your PyPI packages: run sudo pip-3.2 install <package> (installing python packages into your base system requires root, of course).
4. …
5. Profit!

As the package description you linked to says:

In Ubuntu, all python packages use explicit python3 or python2 interpreter and do not use unversioned /usr/bin/python at all ... No packages may declare dependencies on this package.

So, all official Ubuntu packages will depend explicitly on "python2" or "python3", and invoke the appropriate command. The default "python" command is deliberately undefined so that any scripts referencing it have to be updated to unambiguously depend on one version or the other.

However, users may have code that relies on the "python" command being available, and know that they can safely point it across their whole system to one version or the other. The python-is-python3 package (and its counterpart, python-is-python2) are a convenient way to set up a symlink for this purpose.

Does python-is-python3 really just create a single symlink? It seems odd to introduce a package for such a bare bones purpose.

Linux distributions are extremely complex systems made up of a large number of simple components. The power of package managers comes in their flexibility to do simple things like this in a unified way. For instance, a server setup script might have a long list of apt packages that an application needs to be installed, and can simply include python-is-python3 in that list. Shipping a package for this purpose is considerably simpler than having a user guide explaining how to manage the symlink manually.

Does the same go for pip, i.e. pip instead of pip3?

Apparently not - according to this LaunchPad bug, the python3 package automatically points pip at pip3 anyway.

If you open up the .deb file for the package (I used 7-Zip), you can see that apart from some documentation, it really does just contain one symlink, to be installed at /usr/bin/python, pointing to /usr/bin/python3.