You are here

Python

Printer-friendly versionPrinter-friendly version

Supported Versions

Typically several versions of Python are supported - and provided - on DICE. The default (as invoked by the python command) will be whatever is provided as standard for the distribution. Here's a summary of installed versions:

DICE SL7 (64-bit)
Version Command Location Notes
2.7 python, python2, python2.7 /usr/lib*/python2.7/ Default version, fully-maintained libraries.
3.4 python3, python3.4 /usr/lib*/python3.4/ Default '3' version, matching libraries installed where possible, plus basics (e.g. venv, pip*)
3.5 scl enable rh-python35 python /opt/rh/rh-python35 Must be enabled via SCL to use, reasonable library set (including pip, numpy, scipy) preinstalled
DICE SL6 (32/64-bit)
Version Command Location Notes
2.6 python, python2, python2.6 /usr/lib*/python2.6/ Default version, fully-maintained libraries.
2.7 python2.7 /usr/lib*/python2.7/ Includes only those libraries required to manage user installation, (e.g. setuptools, pip)
3.4 python3, python3.4 /usr/lib*/python3.4/ Includes only those libraries required to manage user installation, (e.g. venv, pip)

You'll notice that we also carry newer versions where necessary to support research and teaching requirements.

A wide range of modules will be provided for the standard version of Python. We can usually install any others you require where they are available pre-packaged as part of the distribution. To see what is available for installation you can use our Package Search facility. Asking us to handle the installation of Python modules will make your life much easier: not only will we do the initial install onto all DICE machines, but we will also handle any security updates or changes required for operating system upgrades.

DICE-provided modules

Python has a straightforward and powerful mechanism allowing users to install their own modules, which is described below. Because of this alternative, and because providing modules for non-default versions of Python is disproportionately expensive to support and maintain, we normally only install core libraries for these alternative Python versions. However we understand not all modules can be built without assistance and we'll provide any build dependencies needed for such modules (where possible).

We will however install modules for the default version of Python if they would be of wider benefit across DICE. We aim to keep up-to-date with the latest versions of important modules but this is not always possible. Sometimes new versions will not be compatible with the version of Python or the Linux distribution used for the DICE environment. Also, if there is a teaching requirement for a specific version of a module then that will be frozen for the whole of the teaching year. However bear in mind (as detailed below) most modules can be installed and used without our intervention.

Installing modules yourself

If you require newer versions of Python modules for your project then there is a very easy way to install them in your home directory or group space. This is done using the virtualenv / pyvenv and virtualenvwrapper tools. A quick web search reveals that there are many excellent in-depth tutorials available so we will just give a brief taster of the possibilities here.

See also the computing.help page on Installing Software which covers the use of pip without virtualenv.

Getting Started with virtualenv / pyvenv

Note that if you are using one of the SCL-provided versions of Python (e.g. 3.5 on SL7) you will need to prefix the below commands with scl enable rh-python35 <command>, or else run them all inside an SCL shell with scl enable rh-python35 bash (then using ^D or 'exit' to leave the inner shell when you are done).

For the first example let's assume you want to install the latest version of the utterly awesome IPython (though be aware do already provide IPython!) for your project. Firstly we create a new virtual environment (named myproject) and make it active.

cd
# one of...
  virtualenv --distribute myproject  # for python 2.x
  pyvenv myproject  # for python >= 3.4
# then...
cd myproject
source ./bin/activate

You should notice your shell prompt change after sourcing the activate script, it will gain a (myproject) prefix which helps you to identify which virtual environment you are actively using

You can now install pretty much any module you like using the pip or easy_install tools which will have been added to your standard path when the virtual environment was activated. For example:

pip install ipython

Choosing a python version

One good reason to use virtual environments is to use a specific version of Python. If you're using virtualenv, just use the --python command line option when creating your project:

virtualenv --distribute --python=/usr/bin/python2.7 foobar

To use the modules you have installed in your virtual environment, as before, remember to first source the activate script.

virtualenv and Python 3 ("pyvenv")

As of our Python 3.3 / 3.4 installation, virtualenv functionality is provided as part of the core python installation as the tool pyvenv. It lacks most of the additional options of virtualenv as it is tied to the calling version of python but works, and is activated, in exactly the same way, for example:

pyvenv-3.4 foobar
source ./foobar/bin/activate

Tools to use with virtualenv

yolk

A useful tool to have installed is yolk which helps you list the available modules. Again this can be installed with either tool:

pip install yolk

Running the command yolk -l gives output like this:

Python          - 2.6.6        - active development (/usr/lib64/python2.6/lib-dynload)
distribute      - 0.6.34       - active 
ipython         - 1.0.0        - active 
pip             - 1.3.1        - active 
yolk            - 0.4.3        - active 

virtualenvwrapper

To further simplify the process there is a group of tools which are usually referred to as virtualenvwrapper. This is basically a set of shell scripts which make it easy to create multiple virtual environments and then switch them between them as necessary.

  1. To get started you should create a top-level directory into which your virtual environments will be created:
    mkdir $HOME/virtualenvs
    
  2. Set an environment variable for your shell to specify the location of this top-level directory and then call the initialisation script:
    if [ -x /usr/bin/virtualenvwrapper.sh ] ; then
      export WORKON_HOME=$HOME/virtualenvs
      source /usr/bin/virtualenvwrapper.sh
    fi
    

That needs to be done in the configuration file for your chosen shell (usually .bashrc) so that it is run everytime you login. The first time the virtualenvwrapper.sh script is run it will create various directories within your top-level virtual environment directory.

Here are a few example commands:

To create a new virtual environment:

mkvirtualenv myproject

To activate a virtual environment:

workon myproject

It's also useful to note that running workon with no virtual environment name will give you a list of all those available (if any).

To deactivate a virtual environment:

deactivate 
Last reviewed: 
17/03/2016

System Status

Home dirs (AFS)
Network
Mail
Other services
Scheduled downtime

Choose a topic