Ticket14 docs webpage

.github/workflows/documentation.yml

@@ -0,0 +1,8 @@
+name: sphinx
+
+on: [push, pull_request, workflow_call]
+
+jobs:
+  call_sphinx_builder:
+    uses: ISISComputingGroup/reusable-workflows/.github/workflows/sphinx.yml@main
+    secrets: inherit

.gitignore

@@ -158,3 +158,7 @@ cython_debug/
 .vscode/
 
 coverage_html_report/
+
+# Sphinx generated
+doc/generated/*
+_build/

doc/_api.rst

@@ -0,0 +1,12 @@
+:orphan:
+
+API
+===
+
+.. autosummary::
+   :toctree: generated
+   :template: custom-module-template.rst
+   :recursive:
+
+   ibex_bluesky_core
+

doc/_templates/custom-module-template.rst

@@ -0,0 +1,40 @@
+
+
+{{ ('``' + fullname + '``') | underline }}
+
+{%- set filtered_members = [] %}
+{%- for item in members %}
+    {%- if item in functions + classes + exceptions + attributes %}
+        {% set _ = filtered_members.append(item) %}
+    {%- endif %}
+{%- endfor %}
+
+.. automodule:: {{ fullname }}
+    :members:
+    :show-inheritance:
+
+    {% block modules %}
+    {% if modules %}
+    .. rubric:: Submodules
+
+    .. autosummary::
+        :toctree:
+        :template: custom-module-template.rst
+        :recursive:
+    {% for item in modules %}
+        {{ item }}
+    {%- endfor %}
+    {% endif %}
+    {% endblock %}
+
+    {% block members %}
+    {% if filtered_members %}
+    .. rubric:: Members
+
+    .. autosummary::
+        :nosignatures:
+    {% for item in filtered_members %}
+        {{ item }}
+    {%- endfor %}
+    {% endif %}
+    {% endblock %}

doc/architectural_decisions/001-repo-structure.md

@@ -1,19 +1,19 @@
 # Repository structure
 
-### Status
+## Status
 
 Current
 
-### Context
+## Context
 
 We need to decide how to structure our bluesky and scans code, in 
 terms of technical repository layout.
 
-### Present
+## Present
 
 Tom & Kathryn
 
-### Decision
+## Decision
 
 We will create a `core` repository, and publish it on PyPI.
 
@@ -31,7 +31,7 @@ depend on this repository.
 This `core` repository is analogous to a similar repo, `dodal`, being used at
 Diamond.
 
-### Consequences
+## Consequences
 
 - We will have some bluesky code across multiple repositories.
 - Other groups should be able to:

doc/architectural_decisions/002-use-ophyd-async.md

@@ -1,10 +1,10 @@
 # Use `ophyd-async`
 
-### Status
+## Status
 
 Current
 
-### Context
+## Context
 
 We need to decide whether to use `ophyd` or `ophyd-async` as our bluesky
 device abstraction layer.
@@ -20,15 +20,15 @@ The *primary* differences are:
 - `ophyd-async` has better support for non-channel-access backends (notably, PVA)
 - Reduction in boilerplate
 
-### Present
+## Present
 
 Tom & Kathryn
 
-### Decision
+## Decision
 
 We will use `ophyd-async`.
 
-### Consequences
+## Consequences
 
 - `ophyd-async` will allow us to use PVAccess easily.
 - `ophyd-async` will allow us to do fly scanning, if required in future, more easily than `ophyd`

doc/architectural_decisions/003-run-in-process.md

@@ -1,26 +1,26 @@
 # Run in-process
 
-### Status
+## Status
 
 Current
 
-### Context
+## Context
 
 `bluesky` code can be run in several ways:
 - By the user at an interactive shell, directly calling the run engine in-process.
 - By a central worker process, to which the user would "submit" plans to run.
   - See DLS's `blueapi` for an example of a REST API for submitting plans to the run engine.
 
-### Present
+## Present
 
 Tom & Kathryn
 
-### Decision
+## Decision
 
 We will run bluesky plans in-process for now, while not _excluding_ the possibility
 that they could be run behind a worker process at some point in future.
 
-### Consequences
+## Consequences
 
 - We will not, at least initially, have to write or use an extra worker process.
 - Users will have the ability to call the run engine directly

doc/conf.py

@@ -0,0 +1,48 @@
+# Configuration file for the Sphinx documentation builder.
+#
+# For the full list of built-in configuration values, see the documentation:
+# https://www.sphinx-doc.org/en/master/usage/configuration.html
+
+# -- Project information -----------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#project-information
+
+import os
+import sys
+
+sys.path.insert(0, os.path.abspath("../src"))
+
+project = "ibex_bluesky_core"
+copyright = ""
+author = "ISIS Experiment Controls"
+release = "0.1"
+
+
+# -- General configuration ---------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#general-configuration
+
+extensions = [
+    "myst_parser",
+    "sphinx.ext.autodoc",
+    # and making summary tables at the top of API docs
+    "sphinx.ext.autosummary",
+    # This can parse google style docstrings
+    "sphinx.ext.napoleon",
+    # For linking to external sphinx documentation
+    "sphinx.ext.intersphinx",
+    # Add links to source code in API docs
+    "sphinx.ext.viewcode",
+]
+napoleon_google_docstring = True
+napoleon_numpy_docstring = False
+
+templates_path = ["_templates"]
+exclude_patterns = ["_build", "Thumbs.db", ".DS_Store"]
+
+
+# -- Options for HTML output -------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-html-output
+
+html_theme = "sphinx_rtd_theme"
+html_static_path = ["_static"]
+
+autoclass_content = "both"

doc/create_a_release.md → doc/dev/create_a_release.md

@@ -1,4 +1,4 @@
-### Release Process
+# Release Process
 
 Releases are created automatically via a github action. 
 

doc/set_up_dev_environment.md → doc/dev/set_up_dev_environment.md

@@ -1,40 +1,40 @@
-## Local development
+# Local development
 
-### Checkout the repository locally
+## Checkout the repository locally
 
 ```
 cd c:\Instrument\Dev
 git clone https://github.com/ISISComputingGroup/ibex_bluesky_core.git
 ```
 
-### Create & activate a python virtual environment (windows):
+## Create & activate a python virtual environment (windows):
 
 ```
 cd c:\Instrument\Dev\ibex_bluesky_core
 python -m venv .venv
 .venv\Scripts\activate
 ```
 
-### Install the library & dev dependencies in editable mode:
+## Install the library & dev dependencies in editable mode:
 ```
 python -m pip install -e .[dev]
 ```
 
-### Run the unit tests:
+## Run the unit tests:
 ```
 python -m pytest
 ```
 > [!TIP]  
 > To debug the tests in pycharm, use `--no-cov` as an additional option to your run configuration. There is a conflict [issue](https://youtrack.jetbrains.com/issue/PY-20186/debugging-of-py.test-does-not-stop-on-breakpoints-if-coverage-plugin-enabled) with the pytest-cov module which breaks the debugger.
 
-### Run lints:
+## Run lints:
 ```
 ruff format --check
 ruff check
 pyright
 ```
 
-### Run the 'demo' plan
+## Run the 'demo' plan
 
 Option 1: from a terminal:
 
@@ -64,3 +64,9 @@ set "EPICS_CA_AUTO_ADDR_LIST=NO"
 - You have an IBEX server running with a DAE in setup state, which can begin a simulated run
 - You have a readable & writable block named "mot" in the current configuration pointing at 
 the type of block expected by `demo_plan`
+
+## Build docs locally
+
+To build the sphinx documentation locally run `sphinx-build doc _build` from the root of the repo. The generated output will be in the _build directory.
+
+If you want to preview changes live, you can run `sphinx-autobuild doc _build --watch src` from the root of the repo instead which will start a local, hot-reloadable web server. This should rebuild the documentation whenever you change anything in src, which in turn will rebuild the API reference pages.