DiamondLightSource / DiamondLightSource/blueapi
Favour village extended image over scratch area
- Dominant language
- Python
- Stars
- 13
- Forks
- 13
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 25
Description
With copier template 5.0 switching to uv and its better handling of git submodule dependencies, and the finalising of our debugging in the cluster behaviour, we may be able to remove the scratch config from blueapi.
Instead handle mutability by having known to be needed to be editable dependencies (e.g. dodal) as submodules of the village plan repositories.
e.g.
```
village_bluesky/
src/
dodal/ # submodule, version managed by renovate
pyproject.toml
uv.lock # points dodal -> ./dodal, managed by renovate
Dockerfile
```
Where the Dockerfile looks something like
```
FROM ... as developer
# Devcontainer build as normal
FROM bluesky: # managed by renovate, does NOT depend on dodal
# WORKDIR is /workspaces
COPY --chown=1000:1000 . village_bluesky
# If running as non-1000, i.e. hostNetwork or mounting /dls*
RUN chmod o+wrX village_bluesky
RUN uv sync village_bluesky
```
We probably need to maintain the scratch area for ophyd-async/other dependencies that we don't want to always have an editable version of (hopefully ophyd-async can mostly be debugged offline?) but may in an emergency.
`/workspaces` gets copied into a PVC in an initContainer
`/workspaces_git` is a PVC created when a scratchConfig is configured
## Acceptance Criteria
- Editable modules are controlled by science villages in their Dockerfiles instead of blueapi scratch config
- Editable modules can all be edited in a standard devcontainer attach
- Changes to village_bluesky, dodal can both be hot-reloaded into a running blueapi container
- Breakpoints in village_bluesky, dodal, blueapi can all be caught in debug mode
Contributor guide
Assessment
This issue has not been assessed yet.