You are here


Printer-friendly versionPrinter-friendly version


Some taught courses maintain a shared conda environment. It's normally enabled automatically for students on these courses. Ask your TA or course organiser for details.

Python 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.6 (64-bit) As of Sep 2019
Version Command Location Notes
2.7 python, python2, python2.7 /usr/lib*/python2.7/ Default version, fully-maintained libraries. Python 2.7 will be deprecated by 2020
3.6 python3, python3.6 /usr/lib*/python3.6/ on desktops and most machines Default '3' version, fully-maintained libraries including scipy, numpy, etc. Also includes environment-building tools such as venv and pip3.
3.6 scl enable rh-python36 python /opt/rh/rh-python36 on other hosts Must be enabled via SCL to use; includes comprehensive scientific library set (including pip, numpy, scipy) preinstalled
3.7 Not yet available; Recommend installing from source for now.

Python modules on DICE

Python has a straightforward and powerful mechanism to allow users to install their own modules, 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 sometimes 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 python modules yourself

If your project needs newer versions of Python modules, there is a very easy way to install them in your home directory or group space: use the virtualenv / pyvenv and virtualenvwrapper tools. A web search reveals excellent in-depth tutorials so we will just give a brief taster here.

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

Getting Started with virtualenv and pyvenv

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


yolk 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, make a top-level directory to contain your virtual environments:
    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 .brc) 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:

Last reviewed: 

System Status

Home dirs (AFS)
Other services
Scheduled downtime

Choose a topic