Installation

Prerequisites

PYME requires:

  • Python (2.5 or 2.6, might work with 2.7) *
  • a c compiler*
  • python-dev (only on Linux - has the Python development header files)

and the following Python packages:

  • Numpy*
  • Scipy*
  • Matplotlib*
  • wxPython* (>2.8.11)
  • pytables*
  • Pyro (3.9.1)
  • PyOpenGL*
  • PIL (Python Imaging Library)*
  • pywin32* (only req. on windows)
  • multiprocessing* (Python 2.5 only - part of standard libraries for newer versions on Python)

For full functionality, the following are also useful:

  • PySerial
  • PyParallel
  • MySQL-python
  • Django (>1.2)
  • Mayavi2*
  • Delny

* part of Enthought python.

On Windows (and probably MacOS) the easiest way to get the pre-requisites is to install the Enthought Python Distribution and then pull the remaining packages using pip or easy_install. Under linux I’d use the default python install and the distribution packages for the rest. Depending on how old your distro is you might want to use pip/easy_install for some of the packages to get a more recent version instead (notably Pyro, and WxPython).

There are a couple of little caveats though:

  • We need a very recent version of wxPython. This means you’ll probably have to upgrade the wxPython in EPD (either using pip/easy_install, or by downloading the installer). I found I had to delete the old wx directories and egg file before the new ones would be found because EPD is doing something wierd. In Linux (debian based flavours), the easiest way is to add the relevant repositories and do an apt-get upgrade. On Macs (OS X, the port is generally debugged by Christian) updating wx in EPD involved downloading the latest python2.6 build for OS X (at the time that was wxPython2.8-osx-unicode-2.8.11.0-universal-py2.6.dmg downloaded from www.wxpython.org). I expanded that into a temporary directory and manually moved the relevant directories into the EPD file hierarchy which reside somewhere below /Library/Frameworks/Python.framework/Versions/Current.
  • Delny is a bit of a mess (not in in the python package archive so no easy_install, iffy licensing, need to google, download source, & build, but default sources don’t build on Win or MacOS). I’m trying to remove the dependency (currently only used by one minor component of the visualisation/postprocessing), but in the meantime the easiest thing would probably be to grab a copy of the sources I’ve hacked to work on Win/ Mac off me.
  • On some (most?) versions of windows, the network stack is broken. Pyro needs to be told about this by setting an environment variable - PYRO_BROKEN_MSGWAITALL=1. I can confirm that this is the case for pretty much every XP system, but can’t comment on Vista/7). Pyro falls back on another (slower) piece of code when this the flag is set, so it should be safe in any case. Can’t remember exactly how to diagnose the problem other than that Pyro falls over with cryptic error messages.

To make this whole process of finding and installing dependencies a little less painful, I’ve put together lists of required and recommended modules that can be used with pip to pull any remaining dependencies. Thus one would execute:

pip install -r recommended-modules.txt

to get everything I think is going to be useful, or:

pip install -r required-modules.txt

to get the bare essentials. Obviously this requires pip to be installed first. I would suggest installing at least numpy and scipy manually because pip defaults to building everything from source, which is likely to be somewhat painful for numpy and scipy. On Ubuntu/Debian systems running the install_dependencies.py script will try to install the dependencies using system packages first and then resort to pip for anything left over.

Pyro Nameserver

You need to run a Pyro nameserver somewhere on your network segment. For testing, the easiest thing is to run pryo_ns (or pyro-nsd) from the command line. There can, however, only be one nameserver on the network segment, so long term you might want to find a computer that’s always on and run it on that. If it’s a linux box, there might be some trickery involved to make sure it binds to the the external interface rather than localhost (specifically, the hostname has to resolve to the external interface).

You’ll also want some form of mercurial client if checking out of the repository.

Installing

Create a directory to hold the code. This directory is going to be added to the Python path, so it’s probably not a good idea to just use your home directory, or c:. On Windows I use c:\PYME, on Linux I tend to use ~/PYME.

Get the code

The code is stored in a mercurial repository. If you’re on the local network you can get the current copy by doing

cd ~/PYME
hg clone http://lmsrv1/hg/PYME

or the equivalent using a gui client (eg TortoiseHG). If you’re not on the network, then extract the archive I’ve sent you into this directory.

Build the c extension modules

Open a terminal and execute the following:

c:
cd c:\PYME\PYME
python setup.py build_ext -i

obviously replacing the path with the relevant one. The -i flag tells python to do an inplace build, which is what we want for a development install.

Tell python where to find it

So that python can use the modules it needs to know how to find them. This is done by setting the PYTHONPATH environment variable, by, for example, adding the following line to .profile.

export PYTHONPATH=/home/david/PYME

Note that these instructions are for installing a development copy of PYME (ie in a local directory to which you have write access to). This is usually what you want, there are however a couple of situations (eg when using on a multi-user linux box, or as part of a web server) where you might want to do a more conventional install and have PYME wind up in your Python site-packages directory. To do this, just run sudo python setup.py install rather than python setup.py build_ext -i and dont worry about setting PYTHONPATH.

Windows

Create shortcuts somewhere (eg the start menu), to the following scripts:

  • PYME\Acquire\PYMEAquire.py (data acquisition)
  • PYME\ParallelTasks\launchWorkers.py (real time analysis)
  • PYME\DSView\dh5view.cmd (raw data viewer)
  • PYME\Analysis\LMVis\VisGUI.cmd (analysed data viewer)

Optionally associate .h5 files with dh5view (will also open .tif, .kdf & .psf if you want) and .h5r files with VisGUI. I typically do this by clicking on one of the files, using the ‘Open With’ option, and telling it to remember. If you’re using the sample database, you can also associate .pmu files with PYME.io.FileUtils\pymeUrlOpener.cmd.

Linux (Gnome)

Change to the PYME.io.FileUtils directory and run install_gnome.sh. This should (hopefully) create links to the relevant programs in ~/bin and set up associations and :) thumbnailing! With any luck, file permissions should be OK out of the repository, but there’s a chance you’re going to have to make a couple of the scripts executable.

Basic Configuration

In addition to the setup detailed above, PYME has a couple of configuration options which are controlled by environment variables. These are:

PYME_TASKQUEUENAME Specifies the name of the task queue which processes (analysis/ acquisition) bind to. Needed if you want to run independent analyses on multiple computers.
PYMEDATADIR Default location where PYMEAcquire saves data. Eg D:\. Also place where other parts of analysis chain look for data.
PYMEMICRPATH Used with sample database to know where (on the local machine) the microscope computer is mapped.
PYMENASPATH As for PYMEMICRPATH, but for the NAS

You probably want to set at least PYMEDATADIR, as the default is not particularly useful.

You should now have a setup which works for simulation*, data analysis, & visualisation. Interfacing with hardware obviously requires a little more work - see Configuring PYME Acquire.

* simulation probably won’t work perfectly until you’ve done the EMGain calibration section of Configuring PYME Acquire.