You are here


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.6 scl enable rh-python36 python /opt/rh/rh-python36 Must be enabled via SCL to use, includes comprehensive scientific library set (including pip, numpy, scipy) preinstalled

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 can usually install any others you require where they are available pre-packaged as part of the distribution. Asking us to handle the installation of Python modules can sometimes make your life 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.

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.

Newer versions of Python (3.6+) & development environments

Please see our help page on Software Collections for advice on using the scl utility. Note however that some the scl command may not be required within software such as PyCharm; for this IDE, you only need to add the python binary path (/opt/rh/rh-python36/root/bin/python) to the list of Python Interpreters within Settings.

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 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.

# 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.x installations, 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


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 


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/ ] ; then
      export WORKON_HOME=$HOME/virtualenvs
      source /usr/bin/

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 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:


Other Tools

Certain taught courses maintain a shared conda environment - normally this will be enabled automatically if you take that particular course, and can be added or removed as you wish to any given environment. Ask your TA / course organiser for details.

Last reviewed: 

System Status

Home dirs (AFS)
Other services
Scheduled downtime

Choose a topic