Unsorted Notes
Customizing centrally installed Python distributions 1
Even comprehensive installations require sometimes individual extensions. Part 1.
Our new Python installations provide a large collection of packages. But, some applications that I use are not included at the moment, and, more important, I need a convenient way to adapt the distributions for the purpose of software development. This problem faced many developers before and has been adressed by the package virtualenv quite a while before. It can be used together with any Python version. Moreover, the Python standard library provides an implementation of virtual environments, called venv, starting from version 3.3.
The idea of virtual environments is to provide separated spaces for the installation of individual packages without affecting the central installation on the computer. This even allows to use different, conflicting versions of certain packages in different applications without the need to install complete Python environments repeatedly from scratch.
It is very easy to use virtualenv for every default installation setup. Many tutorials are available online. The Python distributions Anaconda and Canopy include a sophisticated package management that uses virtual environments in order to keep the installation consistent. Moreover, their package and installation managers can serve as replacement of virtualenv also for users.
Customizing Canopy
1. Preparation of the directory for the environment:
$ MY_ENV_ROOT=/cfs/klemming/nobackup/m/michs/pydevel $ mkdir -p $MY_ENV_ROOT
2. Now, the virtual environment that should be used in the future will be created:
$ module load canopy/1.1 $ venv -s $MY_ENV_ROOT/ct1 $ module rm canopy/1.1
The command module load provides access to the central installation of Canopy.
The virtual environment will be created by the command venv. It is important to use an absolute path as installation directory. The option -s specifies that the full environment of the base installation is inherited. That means that access to all packages installed there will be provided also within the new environment. This is implemented by adding the base installation to the Python path (sys.path). However, it is possible to install own versions of packages into the new environment that will have precendence of the packages of the base installation. Without this option one would get an "empty" environment that contains only the Python interpreter and its standard packages.
The environment module canopy/1.1 can be unloaded at this point and is not longer needed.
3. Activation of the new environment:
(ct1) $ source $MY_ENV_ROOT/ct1/bin/activate (ct1) $ python Enthought Canopy Python 2.7.3 | 64-bit | (default, Aug 8 2013, 05:43:23) [GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> ^D (ct1) $ deactivate
In order to use the python installation of the new environment, one has to source the activate script that is contained in the bin directory of the installation. Switching back to the default system environment could be done with the deactivate command.
Own packages can be installed into this environment using distutils, easy_setup, or pip. This will work automatically as long as the environment has been activated. Otherwise, the pathes have to be specified as in usual installation activities. Any other setup method will work too of course.
Continue reading with part two about the customization of Anaconda .
2013-12-30 – Category: programming – Tags: python