2. mx-bluesky repository structure

Date: 2024-08-21

Status

Accepted

Context

Initially, we wanted to separate “application code” such as hyperion from “library code” generic over MX beamlines belonging in mx-bluesky. However, as these were developed together and also together with dodal, dependency management became impossible.

Decision

We will stick to a monorepo repository structure as follows:

mx_bluesky/
├-src/
| └-mx_bluesky/
|   ├-common/               # Plan stubs, utilities, and other common code
|   ├-beamlines/
|   | ├-i03/
|   | ├-i04/
|   | └-i24/
|   |   └-serial/           # Plans for one beamline go in the respective module
|   └-hyperion/             # Plans for more than one beamline go in the top level
├-tests/
| ├-unit_tests/                             # Tests are separated into "unit_tests" and "system_tests"
| | └-{mirror of mx_bluesky structure}/     # Where the former refers to tests which can be run without
| ├-system_tests/                           # access to external services, and the latter might need
| | └-{mirror of mx_bluesky structure}/     # to talk to ISPyB, the DLS filesystem, etc.
| └-test_data/
└-docs/
  ├-developer/
  └-user/

To preserve some of the benefits we would have had from separate repositories, code from beamline or “application” modules (e.g. mx_bluesky.i24.serial or mx_bluesky.hyperion) may import from mx_bluesky.common but not the other way around - this should be enforced with a check in CI.