ophyd-async 0.7.0a1__tar.gz → 0.8.0a2__tar.gz

{ophyd_async-0.7.0a1 → ophyd_async-0.8.0a2}/.copier-answers.yml

@@ -1,5 +1,5 @@
 # Changes here will be overwritten by Copier
-_commit: 2.3.0
+_commit: 2.4.0
 _src_path: gh:DiamondLightSource/python-copier-template
 author_email: tom.cobb@diamond.ac.uk
 author_name: Tom Cobb

{ophyd_async-0.7.0a1 → ophyd_async-0.8.0a2}/.github/CONTRIBUTING.md

@@ -24,4 +24,4 @@ It is recommended that developers use a [vscode devcontainer](https://code.visua
 
 This project was created using the [Diamond Light Source Copier Template](https://github.com/DiamondLightSource/python-copier-template) for Python projects.
 
-For more information on common tasks like setting up a developer environment, running the tests, and setting a pre-commit hook, see the template's [How-to guides](https://diamondlightsource.github.io/python-copier-template/2.3.0/how-to.html).
+For more information on common tasks like setting up a developer environment, running the tests, and setting a pre-commit hook, see the template's [How-to guides](https://diamondlightsource.github.io/python-copier-template/2.4.0/how-to.html).

{ophyd_async-0.7.0a1 → ophyd_async-0.8.0a2}/.github/workflows/_pypi.yml

@@ -15,3 +15,5 @@ jobs:
 
       - name: Publish to PyPI using trusted publishing
         uses: pypa/gh-action-pypi-publish@release/v1
+        with:
+          attestations: false          

{ophyd_async-0.7.0a1 → ophyd_async-0.8.0a2}/Dockerfile

@@ -1,7 +1,7 @@
 # The devcontainer should use the developer target and run as root with podman
 # or docker with user namespaces.
 ARG PYTHON_VERSION=3.11
-FROM python:${PYTHON_VERSION} as developer
+FROM python:${PYTHON_VERSION} AS developer
 
 # Allow Qt 6 (pyside6) UI to work in the container - also see apt-get below
 ENV MPLBACKEND=QtAgg

{ophyd_async-0.7.0a1 → ophyd_async-0.8.0a2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: ophyd-async
-Version: 0.7.0a1
+Version: 0.8.0a2
 Summary: Asynchronous Bluesky hardware abstraction code, compatible with control systems like EPICS and Tango
 Author-email: Tom Cobb <tom.cobb@diamond.ac.uk>
 License: BSD 3-Clause License
@@ -41,12 +41,12 @@ Requires-Python: >=3.10
 Description-Content-Type: text/markdown
 License-File: LICENSE
 Requires-Dist: networkx>=2.0
-Requires-Dist: numpy<2.0.0
+Requires-Dist: numpy
 Requires-Dist: packaging
 Requires-Dist: pint
-Requires-Dist: bluesky>=1.13.0a3
-Requires-Dist: event_model
-Requires-Dist: p4p
+Requires-Dist: bluesky>=1.13
+Requires-Dist: event-model>=1.22.1
+Requires-Dist: p4p>=4.2.0a3
 Requires-Dist: pyyaml
 Requires-Dist: colorlog
 Requires-Dist: pydantic>=2.0
@@ -64,10 +64,6 @@ Requires-Dist: ophyd_async[pva]; extra == "dev"
 Requires-Dist: ophyd_async[sim]; extra == "dev"
 Requires-Dist: ophyd_async[ca]; extra == "dev"
 Requires-Dist: ophyd_async[tango]; extra == "dev"
-Requires-Dist: black; extra == "dev"
-Requires-Dist: flake8; extra == "dev"
-Requires-Dist: flake8-isort; extra == "dev"
-Requires-Dist: Flake8-pyproject; extra == "dev"
 Requires-Dist: inflection; extra == "dev"
 Requires-Dist: ipython; extra == "dev"
 Requires-Dist: ipywidgets; extra == "dev"
@@ -104,9 +100,9 @@ Requires-Dist: types-pyyaml; extra == "dev"
 [![CI](https://github.com/bluesky/ophyd-async/actions/workflows/ci.yml/badge.svg)](https://github.com/bluesky/ophyd-async/actions/workflows/ci.yml)
 [![Coverage](https://codecov.io/gh/bluesky/ophyd-async/branch/main/graph/badge.svg)](https://codecov.io/gh/bluesky/ophyd-async)
 [![PyPI](https://img.shields.io/pypi/v/ophyd-async.svg)](https://pypi.org/project/ophyd-async)
-[![License](https://img.shields.io/badge/License-BSD_3--Clause-blue.svg)](https://opensource.org/licenses/BSD-3-Clause)
+[![License](https://img.shields.io/badge/License-BSD_3--Clause-blue.svg)](https://choosealicense.com/licenses/bsd-3-clause)
 
-# ophyd-async
+# ![ophyd-async](https://raw.githubusercontent.com/bluesky/ophyd-async/main/docs/images/ophyd-async-logo.svg)
 
 Asynchronous Bluesky hardware abstraction code, compatible with control systems like EPICS and Tango.
 
@@ -116,7 +112,7 @@ Asynchronous Bluesky hardware abstraction code, compatible with control systems
 | Documentation |      <https://bluesky.github.io/ophyd-async>      |
 |   Releases    | <https://github.com/bluesky/ophyd-async/releases> |
 
-Ophyd-async is a Python library for asynchronously interfacing with hardware, intended to 
+Ophyd-async is a Python library for asynchronously interfacing with hardware, intended to
 be used as an abstraction layer that enables experiment orchestration and data acquisition code to operate above the specifics of particular devices and control
 systems.
 

{ophyd_async-0.7.0a1 → ophyd_async-0.8.0a2}/README.md

@@ -1,9 +1,9 @@
 [![CI](https://github.com/bluesky/ophyd-async/actions/workflows/ci.yml/badge.svg)](https://github.com/bluesky/ophyd-async/actions/workflows/ci.yml)
 [![Coverage](https://codecov.io/gh/bluesky/ophyd-async/branch/main/graph/badge.svg)](https://codecov.io/gh/bluesky/ophyd-async)
 [![PyPI](https://img.shields.io/pypi/v/ophyd-async.svg)](https://pypi.org/project/ophyd-async)
-[![License](https://img.shields.io/badge/License-BSD_3--Clause-blue.svg)](https://opensource.org/licenses/BSD-3-Clause)
+[![License](https://img.shields.io/badge/License-BSD_3--Clause-blue.svg)](https://choosealicense.com/licenses/bsd-3-clause)
 
-# ophyd-async
+# ![ophyd-async](https://raw.githubusercontent.com/bluesky/ophyd-async/main/docs/images/ophyd-async-logo.svg)
 
 Asynchronous Bluesky hardware abstraction code, compatible with control systems like EPICS and Tango.
 
@@ -13,7 +13,7 @@ Asynchronous Bluesky hardware abstraction code, compatible with control systems
 | Documentation |      <https://bluesky.github.io/ophyd-async>      |
 |   Releases    | <https://github.com/bluesky/ophyd-async/releases> |
 
-Ophyd-async is a Python library for asynchronously interfacing with hardware, intended to 
+Ophyd-async is a Python library for asynchronously interfacing with hardware, intended to
 be used as an abstraction layer that enables experiment orchestration and data acquisition code to operate above the specifics of particular devices and control
 systems.
 

{ophyd_async-0.7.0a1 → ophyd_async-0.8.0a2}/docs/conf.py

@@ -188,9 +188,6 @@ if not switcher_exists:
 # will fix the switcher at the end of the docs workflow, but never gets a chance
 # to complete as the docs build warns and fails.
 html_theme_options = {
-    "logo": {
-        "text": project,
-    },
     "use_edit_page_button": True,
     "github_url": f"https://github.com/{github_user}/{github_repo}",
     "icon_links": [
@@ -230,8 +227,8 @@ html_show_sphinx = False
 html_show_copyright = False
 
 # Logo
-html_logo = "images/bluesky_ophyd_logo.svg"
-html_favicon = "images/ophyd_favicon.svg"
+html_logo = "images/ophyd-async-logo.svg"
+html_favicon = "images/ophyd-favicon.svg"
 
 # If False and a module has the __all__ attribute set, autosummary documents
 # every member listed in __all__ and no others. Default is True

ophyd_async-0.8.0a2/docs/explanations/decisions/0008-signal-types.md

@@ -0,0 +1,159 @@
+# 8. Settle on Signal Types
+Date: 2024-10-18
+
+## Status
+
+Accepted
+
+## Context
+
+At present, soft Signals allow any sort of datatype, while CA, PVA, Tango restrict these to what the control system allows. This means that some soft signals when `describe()` is called on them will give `dtype=object` which is not understood by downstream tools. It also means that load/save will not necessarily understand how to serialize results. Finally we now require `dtype_numpy` for tiled, so arbitrary object types are not suitable even if they are serializable. We should restrict the datatypes allowed in Signals to objects that are serializable and are sensible to add support for in downstream tools.
+
+## Decision
+
+We will allow the following:
+- Primitives:
+    - `bool`
+    - `int`
+    - `float`
+    - `str`
+- Enums:
+    - `StrictEnum` subclass which will be checked to have the same members as the CS
+    - `SubsetEnum` subclass which will be checked to be a subset of the CS members
+- 1D arrays:
+    - `Array1D[np.bool_]`
+    - `Array1D[np.int8]`
+    - `Array1D[np.uint8]`
+    - `Array1D[np.int16]`
+    - `Array1D[np.uint16]`
+    - `Array1D[np.int32]`
+    - `Array1D[np.uint32]`
+    - `Array1D[np.int64]`
+    - `Array1D[np.uint64]`
+    - `Array1D[np.float32]`
+    - `Array1D[np.float64]`
+    - `Sequence[str]`
+    - `Sequence[MyEnum]` where `MyEnum` is a subclass of `StrictEnum` or `SubsetEnum`
+- Specific structures:
+    - `np.ndarray` to represent arrays where dimensionality and dtype can change and must be read from CS
+    - `Table` subclass (which is a pydantic `BaseModel`) where all members are 1D arrays
+
+## Consequences
+
+Clients will be expected to understand:
+- Python primitives (with Enums serializing as strings)
+- Numpy arrays
+- Pydantic BaseModels
+
+All of the above have sensible `dtype_numpy` fields, but `Table` will give a structured row-wise `dtype_numpy`, while the data will be serialized in a column-wise fashion.
+
+The following breaking changes will be made to ophyd-async:
+
+## pvi structure changes
+Structure now read from `.value` rather than `.pvi`. Supported in FastCS. Requires at least PandABlocks-ioc 0.10.0
+## `StrictEnum` is now requried for all strictly checked `Enums`
+```python
+# old
+from enum import Enum
+class MyEnum(str, Enum):
+    ONE = "one"
+    TWO = "two"
+# new
+from ophyd_async.core import StrictEnum
+class MyEnum(StrictEnum):
+    ONE = "one"
+    TWO = "two"
+```
+## `SubsetEnum` is now an `Enum` subclass:
+```python
+from ophyd_async.core import SubsetEnum
+# old
+MySubsetEnum = SubsetEnum["one", "two"]
+# new
+class MySubsetEnum(SubsetEnum):
+    ONE = "one"
+    TWO = "two"
+```
+## Use python primitives for scalar types instead of numpy types
+```python
+# old
+import numpy as np
+x = epics_signal_rw(np.int32, "PV")
+# new
+x = epics_signal_rw(int, "PV")
+```
+## Use `Array1D` for 1D arrays instead of `npt.NDArray`
+```python
+import numpy as np
+# old
+import numpy.typing as npt
+x = epics_signal_rw(npt.NDArray[np.int32], "PV")
+# new
+from ophyd_async.core import Array1D
+x = epics_signal_rw(Array1D[np.int32], "PV")
+```
+## Use `Sequence[str]` for arrays of strings instead of `npt.NDArray[np.str_]`
+```python
+import numpy as np
+# old
+import numpy.typing as npt
+x = epics_signal_rw(npt.NDArray[np.str_], "PV")
+# new
+from collections.abc import Sequence
+x = epics_signal_rw(Sequence[str], "PV")
+```
+## `MockSignalBackend` requires a real backend
+```python
+# old
+fake_set_signal = SignalRW(MockSignalBackend(float))
+# new
+fake_set_signal = soft_signal_rw(float)
+await fake_set_signal.connect(mock=True)
+```
+## `get_mock_put` is no longer passed timeout as it is handled in `Signal`
+```python
+# old
+get_mock_put(driver.capture).assert_called_once_with(Writing.ON, wait=ANY, timeout=ANY)
+# new
+get_mock_put(driver.capture).assert_called_once_with(Writing.ON, wait=ANY)
+```
+## `super().__init__` required for `Device` subclasses
+```python
+# old
+class MyDevice(Device):
+    def __init__(self, name: str = ""):
+        self.signal, self.backend_put = soft_signal_r_and_setter(int)
+# new
+class MyDevice(Device):
+    def __init__(self, name: str = ""):
+        self.signal, self.backend_put = soft_signal_r_and_setter(int)
+        super().__init__(name=name)
+```
+## Arbitrary `BaseModel`s not supported, pending use cases for them
+The `Table` type has been suitable for everything we have seen so far, if you need an arbitrary `BaseModel` subclass then please make an issue
+## Child `Device`s set parent on attach, and can't be public children of more than one parent
+```python
+class SourceDevice(Device):
+    def __init__(self, name: str = ""):
+        self.signal = soft_signal_rw(int)
+        super().__init__(name=name)
+
+# old
+class ReferenceDevice(Device):
+    def __init__(self, signal: SignalRW[int], name: str = ""):
+        self.signal = signal
+        super().__init__(name=name)
+
+    def set(self, value) -> AsyncStatus:
+        return self.signal.set(value + 1)
+# new
+from ophyd_async.core import Reference
+
+class ReferenceDevice(Device):
+    def __init__(self, signal: SignalRW[int], name: str = ""):
+        self._signal_ref = Reference(signal)
+        super().__init__(name=name)
+
+    def set(self, value) -> AsyncStatus:
+        return self._signal_ref().set(value + 1)
+```

{ophyd_async-0.7.0a1 → ophyd_async-0.8.0a2}/docs/how-to/make-a-simple-device.rst

@@ -1,6 +1,6 @@
 .. note::
 
-   Ophyd async is included on a provisional basis until the v1.0 release and 
+   Ophyd async is included on a provisional basis until the v1.0 release and
    may change API on minor release numbers before then
 
 Make a Simple Device
@@ -31,7 +31,7 @@ its Python type, which could be:
 - A primitive (`str`, `int`, `float`)
 - An array (`numpy.typing.NDArray` ie. ``numpy.typing.NDArray[numpy.uint16]`` or ``Sequence[str]``)
 - An enum (`enum.Enum`) which **must** also extend `str`
-    - `str` and ``EnumClass(str, Enum)`` are the only valid ``datatype`` for an enumerated signal.
+    - `str` and ``EnumClass(StrictEnum)`` are the only valid ``datatype`` for an enumerated signal.
 
 The rest of the arguments are PV connection information, in this case the PV suffix.
 
@@ -45,7 +45,7 @@ Finally `super().__init__() <StandardReadable>` is called with:
   without renaming
 
 All signals passed into this init method will be monitored between ``stage()``
-and ``unstage()`` and their cached values returned on ``read()`` and 
+and ``unstage()`` and their cached values returned on ``read()`` and
 ``read_configuration()`` for perfomance.
 
 Movable
@@ -64,7 +64,7 @@ informing watchers of the progress. When it gets to the requested value it
 completes. This co-routine is wrapped in a timeout handler, and passed to an
 `AsyncStatus` which will start executing it as soon as the Run Engine adds a
 callback to it. The ``stop()`` method then pokes a PV if the move needs to be
-interrupted. 
+interrupted.
 
 Assembly
 --------