From 7b5ce1d1655ddc55921b4fd50a8c72b0ad217099 Mon Sep 17 00:00:00 2001 From: Julian Stirling Date: Fri, 11 Jul 2025 12:35:39 +0100 Subject: [PATCH 1/3] Update README to point at CONTRIBUTING and make contributing link to site, then give repository specifics. --- CONTRIBUTING.md | 100 ++++++++++++------------------------------------ README.md | 6 ++- 2 files changed, 29 insertions(+), 77 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 98c78bad..d907b3c0 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,94 +1,44 @@ -# Contributing +# Contributing to the OpenFlexure Microscope Server -When contributing to this repository, please first discuss the change you wish to make via issue, -email, or any other method with the owners of this repository before making a change. +All contributions to the OpenFlexure project should follow our [project contributions guidelines](https://openflexure.org/contribute). -Please note we have a working flow, and a code of conduct. Please follow it in all your interactions with the project. +Any contributions to this repository should follow [our code of conduct](https://openflexure.org/conduct). -## Flow - +If you are interested in contributing to the OpenFlexure project and do not know where to start we recommend you visit [our forum](https://openflexure.discourse.group/). -### Development +**The rest of this page details contribution guidelines that are specific to this repository.** -* Master is the latest working version. -* New features and bug fixes should be developed on branches (or forks), and merged into master. +This page generally focusses on the the server not the front-end webapp. For more details on the webapp development see the [webapp's README](./webapp/README.md). -### Releases +## Python Development -* Once we've merged a few things in and want to make a release, we tag it on master. -* Not every commit on master will get a tag, we'll accumulate a few changes before making a release, unless there's a reason to release straight away. -* Once we're confident that the tagged release is building and stable, we merge it into the stable branch. -* As and when 2.x.x appears, we will move 1.x.x to a branch in case we want to push out bugfixes, but we're not likely to do this for minor releases. +For installation see the [project README](./README.md). -## Code of Conduct +### Core packages and concepts -In the interest of fostering an open and welcoming environment, we as -contributors and maintainers pledge to making participation in our project and -our community a harassment-free experience for everyone, regardless of age, body -size, disability, ethnicity, gender identity and expression, level of experience, -nationality, personal appearance, race, religion, or sexual identity and -orientation. +The OpenFlexure Microscope server is built in the [LabThings-FastAPI framework](https://labthings-fastapi.readthedocs.io/en/latest/). This provides a convenient way to expose laboratory hardware over HTTP via a [FastAPI server](https://fastapi.tiangolo.com/). -### Our Standards +The core elements of the server code are `Things`. A `Thing` creates a [W3C Web of Things](https://www.w3.org/TR/wot-architecture) compliant HTTP interface for hardware interactions and other server functionality. -Examples of behavior that contributes to creating a positive environment -include: +The project also makes use of the following libraries: -* Using welcoming and inclusive language -* Being respectful of differing viewpoints and experiences -* Gracefully accepting constructive criticism -* Focusing on what is best for the community -* Showing empathy towards other community members +* [Pydantic](https://docs.pydantic.dev/latest/) - For serialising/deserialising data being saved to disk or sent over HTTP. +* [OpenFlexure Stitching](https://gitlab.com/openflexure/openflexure-stitching) - Our own library for creating composite microscope images from a scan. +* [OpenCV](https://opencv.org/) and [Picamera2](https://github.com/raspberrypi/picamera2/) - For controlling cameras, and simulating cameras for tests. +* [Pillow](https://pillow.readthedocs.io) - For image manipulation and saving. +* [NumPy](https://numpy.org/) and [SciPy](https://scipy.org/) - For mathematical calculations. -Examples of unacceptable behavior by participants include: +*The list above is not exhaustive!* -* The use of sexualized language or imagery and unwelcome sexual attention or -advances -* Trolling, insulting/derogatory comments, and personal or political attacks -* Public or private harassment -* Publishing others' private information, such as a physical or electronic - address, without explicit permission -* Other conduct which could reasonably be considered inappropriate in a - professional setting +## Programming style -### Our Responsibilities +Ideally python code should be: -Project maintainers are responsible for clarifying the standards of acceptable -behavior and are expected to take appropriate and fair corrective action in -response to any instances of unacceptable behavior. +* Broken up into small clear testable functions. +* Documented with docstrings (For conventions see below). +* Type hinted +* Covered by unit tests -Project maintainers have the right and responsibility to remove, edit, or -reject comments, commits, code, wiki edits, issues, and other contributions -that are not aligned to this Code of Conduct, or to ban temporarily or -permanently any contributor for other behaviors that they deem inappropriate, -threatening, offensive, or harmful. +The server code is going through significant flux during the transition from v2 to v3, so currently our test coverage is being rebuilt and type checking does not yet pass. -### Scope -This Code of Conduct applies both within project spaces and in public spaces -when an individual is representing the project or its community. Examples of -representing a project or community include using an official project e-mail -address, posting via an official social media account, or acting as an appointed -representative at an online or offline event. Representation of a project may be -further defined and clarified by project maintainers. - -### Enforcement - -Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported by contacting the project team at [INSERT EMAIL ADDRESS]. All -complaints will be reviewed and investigated and will result in a response that -is deemed necessary and appropriate to the circumstances. The project team is -obligated to maintain confidentiality with regard to the reporter of an incident. -Further details of specific enforcement policies may be posted separately. - -Project maintainers who do not follow or enforce the Code of Conduct in good -faith may face temporary or permanent repercussions as determined by other -members of the project's leadership. - -### Attribution - -This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, -available at [http://contributor-covenant.org/version/1/4][version] - -[homepage]: http://contributor-covenant.org -[version]: http://contributor-covenant.org/version/1/4/ \ No newline at end of file diff --git a/README.md b/README.md index 45469838..254aa450 100644 --- a/README.md +++ b/README.md @@ -49,7 +49,7 @@ You can manage the server with the `ofm` command, using `ofm start`, `ofm stop`, ofm stop ofm activate cd /var/openflexure -sudo -u openflexure-ws openflexure-microscope-server -c microscope_configuration.json --host 0.0.0.0 --port 5000 +sudo -u openflexure-ws openflexure-microscope-server --fallback -c microscope_configuration.json --host 0.0.0.0 --port 5000 ``` Our favourite way of working with the server on a Pi is to follow the instructions above, then open a VSCode Remote session from another computer. This allows you to use your usual developer environment to write code, but everything runs on the Raspberry Pi with real hardware. Note that the repository is cloned by default over `https`, so you will probably need to change the "remote" URL to your fork of the repository, or to SSH, before you're able to push changes. @@ -103,7 +103,8 @@ The Labthings-FastAPI server, written in Python, serves a web application writte For more details on the web app see the ReadMe in the [webapp](./webapp) directory. -## Formatting, linting, and tests +## Python: Formatting, linting, and tests + All of the commands below assume that you are running in the OFM virtual environment, i.e. you have run `ofm activate` on an OpenFlexure SD card, or `source .venv/bin/activate` on Linux, or `.venv/Scripts/activate`on Windows. **Before committing** you should lint and auto-format your code: @@ -120,6 +121,7 @@ All of the commands below assume that you are running in the OFM virtual environ * `mypy src` (currently fails) * `pytest` +For more details on out Python conventions please see the **[project contributions guide](./CONTRIBUTING.md)**. ### Details From 08aaaa6fe1f2b9b60c29fc5747719e4839cf21ad Mon Sep 17 00:00:00 2001 From: Julian Stirling Date: Fri, 11 Jul 2025 13:00:04 +0100 Subject: [PATCH 2/3] Complete a first pass of updated contributing guidelines. --- CONTRIBUTING.md | 60 ++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 59 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d907b3c0..d6935cad 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -37,8 +37,66 @@ Ideally python code should be: * Broken up into small clear testable functions. * Documented with docstrings (For conventions see below). * Type hinted -* Covered by unit tests +* Covered by unit tests (using [pytest](https://docs.pytest.org)) The server code is going through significant flux during the transition from v2 to v3, so currently our test coverage is being rebuilt and type checking does not yet pass. +[Ruff](https://docs.astral.sh/ruff/) is used both for linting and formatting, the codebase. Our custom linter rules are in out `pyproject.toml`. As we improve the codebase more rules are being added to the linter, see `ruff-increased-checking.toml` for checks that we plan to get passing. +Run `ruff format` to format the code in a way that will pass on our CI. + +Run `ruff check` to check for linter errors. + +To check your code before each commit we recommend putting the following script in tour `.git/hooks` directory with the filename `pre-commit`. + + +```python +#!/bin/bash + +set -e + +function angrymessage() +{ + RED='\033[1;31m' + NC='\033[0m' # No Color + printf "\n${RED}Not committing as ruff failed${NC}\n\n" +} + +trap angrymessage ERR + +ruff format --check +ruff check +``` + + +## Docstrings conventions. + +For docstrings we write docstrings in [reStructuredText](https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html), and process them with [pydoctor](https://pydoctor.readthedocs.io/). + +For function arguments, return values, and exceptions we use the following style recognised by reStructuredText: + +```python +def a_function(arg1: str, arg2: int) -> tuple[float, int]: + """ + A one sentence summary, in imperative mood, ending with punctuation. + + More detail after a blank line. This could be a whole paragraph. + + When referring to ``code`` in reStructuredText used double backticks + + :param arg1: This is the first argument, we can say everything we need to about it. + If the text wrapas ont a new line this line is indented. + :param arg2: This is the second argument. + + :returns: Say what it returns without anything within the colons. If returning + multiple values a bulleted list is a good idea just make sure: + + * It is indented to 1 level in + * There is a blank line before the bullets + * The bullet points are ``*`` not ``-`` + """ +``` + +The linter rules we use for docstrings are defined by [pydocstyle](https://docs.astral.sh/ruff/rules/#pydocstyle-d). We do not use rules D203, D213, D400. + +The documentation generated by pydoctor from docstrings can be viewed in any merge request (if the CI pipeline has passed) using the "View App" button. From cef3c9f40dbce2f0f0ef7c9c2a6021b72a70c83f Mon Sep 17 00:00:00 2001 From: Julian Stirling Date: Fri, 11 Jul 2025 16:14:03 +0000 Subject: [PATCH 3/3] Apply suggestions from code review of branch update-readme-and-contributing Co-authored-by: Joe Knapper --- CONTRIBUTING.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d6935cad..e5add077 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -2,17 +2,17 @@ All contributions to the OpenFlexure project should follow our [project contributions guidelines](https://openflexure.org/contribute). -Any contributions to this repository should follow [our code of conduct](https://openflexure.org/conduct). +Any contributions to any of our projects should follow [our code of conduct](https://openflexure.org/conduct). -If you are interested in contributing to the OpenFlexure project and do not know where to start we recommend you visit [our forum](https://openflexure.discourse.group/). +If you are interested in contributing to the OpenFlexure project, and do not know where to start, we recommend you visit [our forum](https://openflexure.discourse.group/). **The rest of this page details contribution guidelines that are specific to this repository.** -This page generally focusses on the the server not the front-end webapp. For more details on the webapp development see the [webapp's README](./webapp/README.md). +This page generally focusses on the back-end of the server, not the front-end webapp. For more details on the webapp development see the [webapp's README](./webapp/README.md). ## Python Development -For installation see the [project README](./README.md). +For installation, see the [project README](./README.md). ### Core packages and concepts @@ -32,20 +32,20 @@ The project also makes use of the following libraries: ## Programming style -Ideally python code should be: +Ideally, python code should be: -* Broken up into small clear testable functions. +* Broken up into small, clear, testable functions. * Documented with docstrings (For conventions see below). * Type hinted * Covered by unit tests (using [pytest](https://docs.pytest.org)) The server code is going through significant flux during the transition from v2 to v3, so currently our test coverage is being rebuilt and type checking does not yet pass. -[Ruff](https://docs.astral.sh/ruff/) is used both for linting and formatting, the codebase. Our custom linter rules are in out `pyproject.toml`. As we improve the codebase more rules are being added to the linter, see `ruff-increased-checking.toml` for checks that we plan to get passing. +[Ruff](https://docs.astral.sh/ruff/) is used both for linting and formatting the codebase. Our custom linter rules are in our `pyproject.toml`. As we improve the codebase, more rules are being added to the linter; see `ruff-increased-checking.toml` for checks that we plan to get passing. Run `ruff format` to format the code in a way that will pass on our CI. -Run `ruff check` to check for linter errors. +Run `ruff check` to check for linter errors. Any contributions that don't pass both of these checks will be automatically rejected by our pipeline. To check your code before each commit we recommend putting the following script in tour `.git/hooks` directory with the filename `pre-commit`. @@ -71,7 +71,7 @@ ruff check ## Docstrings conventions. -For docstrings we write docstrings in [reStructuredText](https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html), and process them with [pydoctor](https://pydoctor.readthedocs.io/). +We write docstrings in [reStructuredText](https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html), and process them with [pydoctor](https://pydoctor.readthedocs.io/). For function arguments, return values, and exceptions we use the following style recognised by reStructuredText: @@ -85,11 +85,11 @@ def a_function(arg1: str, arg2: int) -> tuple[float, int]: When referring to ``code`` in reStructuredText used double backticks :param arg1: This is the first argument, we can say everything we need to about it. - If the text wrapas ont a new line this line is indented. + If the text wraps onto a new line, this line is indented. :param arg2: This is the second argument. :returns: Say what it returns without anything within the colons. If returning - multiple values a bulleted list is a good idea just make sure: + multiple values, a bulleted list is a good idea - just make sure: * It is indented to 1 level in * There is a blank line before the bullets @@ -97,6 +97,6 @@ def a_function(arg1: str, arg2: int) -> tuple[float, int]: """ ``` -The linter rules we use for docstrings are defined by [pydocstyle](https://docs.astral.sh/ruff/rules/#pydocstyle-d). We do not use rules D203, D213, D400. ++The linter rules we use for docstrings are defined by [pydocstyle](https://docs.astral.sh/ruff/rules/#pydocstyle-d). We do not use rules D203, D213, D400 for reasons explained in our `pyproject.toml` file. The documentation generated by pydoctor from docstrings can be viewed in any merge request (if the CI pipeline has passed) using the "View App" button.