Lab Installation

Introduction

This page describes how the common lab files are shared among different experiments, while each experiment also maintains its own git repository. It may be useful to read through the git instructions before proceeding.

Directory Structure

Each experiment uses two git repositories: Haeffner-Lab-LabRAD-Tools for common servers and clients and one containing code that is only useful for that experiment. To achieve this, we use the following directory structure

LabRAD\
       __init__.py
       \common\...
       \experiment_name\...

where common is the cloned Haeffner-Lab-LabRAD-Tools repository and experiment_name is the experiment-specific repository. The file __init__.py is an empty file that indicates it's in a package. This allows for easy import of files from either directory using:

import common.folder.file

To achieve this, add the LabRAD directory to PYTHONPATH in /etc/.bashrc on Linux or Mac.

export PYTHONPATH=$HOME/LabRAD/:$PYTHONPATH

LabRAD Registry

While the Manager is distributed with the common files, The Registry is experiment-specific and belongs in the /experiment_name/ folder. One can place it there as long as the the location is updated in LabRAD Manager.

Using the common files

We run any of the common code directly from the /common/ folder, without making additional copies. For example: the node server looks inside /common/ for available servers, and the central GUI imports widgets from /common/clients/ . With this method, we avoid unnecessary duplication and version-tracking. The common files can easily be updated by running

git pull

from the /common/ directory.

Experiment-specific settings

When a server or a client requires additional settings, these will be contained in a separate configuration file, i.e ''config.py''. When this is the case an example file for the configuration will be provided and names ''config.py'.example''. The experiment should then make a copy of this file and rename it to ''config.py''. In order to avoid pushing the experiment-specific file back to git, add it the list of files ignored by git ''.gitignore''.

Lab Development

The common files are shared among all the experiments and, as such one has to be careful updating them. An incorrect update that breaks a server or a client and is pushed up to the master branch will propagated as soon as any experiments runs git pull.

If a change is trivial such as deleting an empty line, or putting in a useful print statement, or adding a new server, one can make the change and push it up. However for more serious updates, please follow the guidelines below:

1. Run git pull to make sure the master branch is up to date.

2. Make a new development branch from the master with a descriptive name: git branch branch_name

3. Check out the new development branch and make the necessary changes. One can test these changes with own experimental code. We should try to be as backwards-compatible as possible, especially for mature servers.

4. Make sure there have been no other changes to the master branch since you made the development branch. If there have, you need to first merge those into the development branch before proceeding. Push the development branch to github for review: git push origin branch_name. Let the person responsible know that you've made a change that needs review.

5. If the change is accepted, it will be merged into the master branch. One can then delete the branch branch_name.