Installing alternate versions of Python in CentOS
The downside of running CentOS is that, for a lot of packages, the versions are far from bleeding edge.
Python is used by serveral critical system utilities (such as yum) which will break if you replace the system version of python. If you want a version of python other than the supported version, here's how.
This will work for versions in both the 2.x and 3.x branches, with some minor differences.
Compiling python is not difficult, but we will need some prerequisites first. It's really important to have all the devel packages otherwise python will be missing support for various things (like if you don't have openssl-devel installed, none of the python libraries will know how to handle https).
yum groupinstall "Development tools"
yum install zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gdbm-devel db4-devel libcap-devel xz-devel
You should consider the following...
Unicode
Python 3.2 and earlier should have UTF-32 support configured (otherwise you may run into problems). From Python 3.3 and upward Unicode support has been completely overhauled and strings are automatically stored in the most efficient encoding.
For Python 2.x use the --enable-unicode=ucs4
flag to the configure command. In Python 3.x use --with-wide-unicode
.
Shared Library
You should probably compile Python as a shared library. All modern linux distros ship with Python compiled as a shared library, and there are third party tools that won't work without it. If you compile Python as a shared library you must also tell it how to find the library. There are two options.
- Compile the path into the executable by adding this to the configure command:
LDFLAGS="-Wl,-rpath /usr/local/lib"
- Add the library's path to
/etc/ld.so.conf
include ld.so.conf.d/*.conf /usr/local/lib
Use "make altinstall" to prevent issues
It is vitally important that you use make altinstall
when you install your custom version of python.
Download, Compile, Install
I'm installing Python 3.4.1 as a shared library, with it's path compiled into the executable, so am including the LDFLAGS
as discussed. If you are not you can omit this, but don't forget to edit /etc/ld.so.conf
and you will need to run /sbin/ldconfig
to pick up the changes. Your mileage may vary.
wget http://python.org/ftp/python/3.4.1/Python-3.4.1.tar.xz
tar xf Python-3.4.1.tar.xz
cd Python-3.4.1
./configure --prefix=/usr/local --enable-shared LDFLAGS="-Wl,-rpath /usr/local/lib"
make && make altinstall
Once that has completed you will have a shiny new Python 3.4.1 available as /usr/local/bin/python3.4
which (on our systems which are using 2.6.6 as the system python) I symlink to /usr/local/python3
. It's up to you if you want to do that.
Setuptools and pip
In our case these are probably not needed as we dont want end users using them, but here's how.
wget https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py
python3.4 ez_setup.py
easy_install-3.4 pip
Packages installed using pip3.4 install [packagename]
will end up in /usr/local/lib/python3.4/site-packages/
.
Virtualenv
If you are using different versions of python on a single machine, you should really be using virtualenv. Python 3.3 has this built in, for lower versions you will need to install it. For example if you have installed Python 2.7, pip2.7 install virtualenv
.
Then using virtualenv create a sandbox for each project.
vertualenv-2.7 myProject
# The builtin version is pyvenv
pyvenv-3.4 my34project
# Use like this
source my34project/bin/activate
python --version
# this will show Python 3.4.1
deactivate
# source myProject/bin/activate
python --version
# this will show Python 2.7.6, for example
deactivate
Don't forget, virtualenv will automagically install setuptools and pip for you inside the sandbox. If you are using pyvenv, that's up to you, I'm afraid. ez_setup.py
is your friend, here.