|
| 1 | +# AI Agents Documentation |
| 2 | + |
| 3 | +This document provides guidance for AI agents (like Claude, Junie, etc.) working on the `plotting-service` repository. |
| 4 | + |
| 5 | +## Project Overview |
| 6 | + |
| 7 | +The `plotting-service` is a FastAPI application that provides a [h5-grove](https://github.com/silx-kit/h5grove) implementation for serving and plotting scientific data, specifically targeting NeXus/HDF5 files and IMAT image data. |
| 8 | + |
| 9 | +### Core Technologies |
| 10 | +- **FastAPI**: Web framework. |
| 11 | +- **h5grove**: Backend for HDF5/NeXus data access. |
| 12 | +- **Pillow**: Image processing (for IMAT data). |
| 13 | +- **Pytest**: Testing framework. |
| 14 | +- **Ruff**: Linting and formatting. |
| 15 | + |
| 16 | +## Repository Structure |
| 17 | + |
| 18 | +- `plotting_service/`: Main package. |
| 19 | + - `plotting_api.py`: Application entry point and middleware (authentication). |
| 20 | + - `routers/`: API route definitions. |
| 21 | + - `plotting.py`: Generic file finding and text retrieval. |
| 22 | + - `imat.py`: IMAT-specific image data routes. |
| 23 | + - `live_data.py`: Routes for handling live data streams. |
| 24 | + - `services/`: Business logic. |
| 25 | + - `image_service.py`: PIL-based image processing. |
| 26 | + - `utils.py`: Path manipulation and file searching logic. |
| 27 | +- `test/`: Test suite. |
| 28 | +- `pyproject.toml`: Project metadata and dependencies. |
| 29 | +- `Dockerfile`: Containerization setup. |
| 30 | + |
| 31 | +## Development Workflow |
| 32 | + |
| 33 | +### Setup |
| 34 | + |
| 35 | +The project aims to be agnostic regarding local developer setups. |
| 36 | + |
| 37 | +#### Using Conda (Recommended if available) |
| 38 | +If you use conda, check if the `plotting-service` environment exists. If not, create it and install dependencies: |
| 39 | + |
| 40 | +```bash |
| 41 | +# Check if conda is installed |
| 42 | +which conda |
| 43 | + |
| 44 | +# Check if environment exists |
| 45 | +conda env list | grep plotting-service |
| 46 | + |
| 47 | +# If it doesn't exist, create it (Python 3.11+) |
| 48 | +conda create -n plotting-service "python>=3.11" -y |
| 49 | + |
| 50 | +# Activate and install dependencies |
| 51 | +conda activate plotting-service |
| 52 | +pip install .[all,test,formatting] |
| 53 | +``` |
| 54 | + |
| 55 | +#### Using Pip/Venv (Fallback if conda is not available) |
| 56 | +If conda is not installed or you prefer standard virtual environments: |
| 57 | + |
| 58 | +```bash |
| 59 | +python -m venv venv |
| 60 | +source venv/bin/activate |
| 61 | +pip install .[all,test,formatting] |
| 62 | +``` |
| 63 | + |
| 64 | +### Running the API (Development) |
| 65 | +```bash |
| 66 | +uvicorn plotting_service.plotting_api:app --reload |
| 67 | +``` |
| 68 | + |
| 69 | +### Running Tests |
| 70 | +```bash |
| 71 | +pytest |
| 72 | +``` |
| 73 | + |
| 74 | +### Branch Naming |
| 75 | + |
| 76 | +Branches should use snake_case descriptions of the work being done. Do not use category prefixes (like `feature/` or `fix/`). |
| 77 | + |
| 78 | +- **Format**: `description_of_work` (e.g., `update_agent_guidelines`). |
| 79 | + |
| 80 | +### Creating Issues |
| 81 | + |
| 82 | +To ensure issues are consistent and contain necessary context, use the repository's issue template. You can fetch and use the latest template directly via the GitHub CLI: |
| 83 | + |
| 84 | +```bash |
| 85 | +gh issue create --template Issue |
| 86 | +``` |
| 87 | + |
| 88 | +Filling this in will provide the correct template for Features or Bugs as appropriate. |
| 89 | + |
| 90 | +### Pull Request Process |
| 91 | + |
| 92 | +1. **Local Validation**: Before opening a PR, ensure all tests pass and code quality checks are green. |
| 93 | + ```bash |
| 94 | + pytest |
| 95 | + ruff check . |
| 96 | + mypy plotting_service |
| 97 | + ``` |
| 98 | +2. **PR Description**: Use the "## Description" header followed by a clear explanation of your changes. |
| 99 | +3. **Reference Issues**: Link any related issues in the description (e.g., "Closes #123"). |
| 100 | + |
| 101 | +### Handling Dependabot PRs |
| 102 | + |
| 103 | +Dependabot periodically creates pull requests to update dependencies and GitHub Actions. Agents should follow this workflow: |
| 104 | + |
| 105 | +1. **List and Identify**: Use `gh pr list` to find open Dependabot PRs. |
| 106 | +2. **Review Changes**: Inspect the changes with `gh pr diff <number>`. Pay close attention to major version bumps in `pyproject.toml` or changes in `.github/workflows/`. |
| 107 | +3. **Validation**: |
| 108 | + - **Python/Dependency changes**: If `pyproject.toml` or Python files are modified, perform local validation: |
| 109 | + - Checkout the PR branch: `gh pr checkout <number>`. |
| 110 | + - Run the full test suite: `pytest`. |
| 111 | + - Run linting and type checking: `ruff check .` and `mypy plotting_service`. |
| 112 | + - **GitHub Actions changes**: If `.github/workflows/` are modified, check that the actions have passed as part of the PR: |
| 113 | + - `gh pr checks <number>` |
| 114 | +4. **Approve and Merge**: |
| 115 | + - If validation passes, approve the PR: `gh pr review <number> --approve`. |
| 116 | + - Merge the PR: `gh pr merge <number> --merge`. |
| 117 | + - **Note**: Use the `--admin` flag if the merge is blocked by branch protection policies (e.g., `gh pr merge <number> --merge --admin`). |
| 118 | +5. **Clean up**: Close redundant or superseded PRs using `gh pr close <number> --delete-branch`. |
| 119 | +6. **Final Verification**: After merging, return to the `main` branch, pull the latest changes, and run `pytest` one last time to ensure everything is correct. |
| 120 | + |
| 121 | +### Agent Guidelines |
| 122 | + |
| 123 | +#### Environment Setup |
| 124 | +Agents should prefer using a conda environment named `plotting-service` if conda is available on the system PATH. |
| 125 | + |
| 126 | +If conda is not available, the agent should fallback to using a standard Python virtual environment (`venv`). |
| 127 | + |
| 128 | +If an environment does not exist, the agent should offer to create it and install requirements from `pyproject.toml`. |
| 129 | + |
| 130 | +### Path Handling |
| 131 | +The service heavily relies on environment variables for data locations: |
| 132 | +- `CEPH_DIR`: Base directory for reduced data (e.g., `/ceph`). |
| 133 | +- `IMAT_DIR`: Base directory for IMAT data (e.g., `/imat`). |
| 134 | + |
| 135 | +When working with file paths, use `pathlib.Path` and ensure compatibility with the directory structures expected by `utils.py`. |
| 136 | + |
| 137 | +### Authentication |
| 138 | +The API implements JWT-based authentication and API key checks in `plotting_api.py`. Be aware of `check_permissions` and `check_live_permissions` middleware when adding or modifying routes. |
| 139 | + |
| 140 | +### Testing |
| 141 | +- Always include/update tests in the `test/` directory. |
| 142 | +- Use the existing test structure (e.g., `test_plotting_api.py`) as a template. |
| 143 | +- Test data is often mocked or provided in `test/test_ceph`. |
| 144 | + |
| 145 | +### Formatting |
| 146 | +The project uses `Ruff` for linting and formatting. Ensure your changes comply with the rules defined in `pyproject.toml`. |
0 commit comments