Skip to content

Initial ophyd-async support - #1188

Open
canismarko wants to merge 5 commits into
BCDA-APS:mainfrom
spc-group:async
Open

Initial ophyd-async support#1188
canismarko wants to merge 5 commits into
BCDA-APS:mainfrom
spc-group:async

Conversation

@canismarko

Copy link
Copy Markdown
Collaborator

Haven contains a number of ophyd-async devices that could be useful for other beamlines. I am hoping to start moving some of these into apstools since ophyd-async is getting close to its first stable release. Ophyd-async is especially good for fly-scanning detectors, which seems useful to others.

This PR:

  • adds ophyd-async as a dependency
  • includes a simple ophyd-async device (aps machine)

I put the ophyd-async devices in a new _devices_async package so existing deployments shouldn't be affected. I also added ophyd-async as an optional dependency (pip install apstools[async]). My thought was that once ophyd-async is stable, we can rename this package to devices_async and make ophyd-async a default dependency to indicate that this support is ready for general use.

The current release of ophyd-async depends on python >= 3.11. How important is maintaining python 3.10 support? It is schedule to go end-of-life in October.

Async support is an optional dependency to not break backwards
compatability. Ophyd-async requies python>=3.11 but apstools can make
do with python>=3.10.
We might want change this without notice ophyd-async devices without
notice, so renaming the package makes it clear that this is not meant
to be stable.
@prjemian

Copy link
Copy Markdown
Contributor

Py 3.10 is close to end of support. It's safe for you to drop it from the test matrix here.

@prjemian prjemian added this to the async devices - 1.8.0 milestone Aug 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants