make device factory decorator

[stan-dot]

Fixes #483

Instructions to reviewer on how to test:

1. Do thing run i22 beamline
2. Confirm lazy loading is possible

Checks for reviewer

• Would the PR title make sense to a scientist on a set of release notes
• If a new device has been added does it follow the standards
• If changing the API for a pre-existing device, ensure that any beamlines using this device have updated their Bluesky plans accordingly
• Have the connection tests for the relevant beamline(s) been run via dodal connect ${BEAMLINE}

[coretl]

No idea if the rest of the code is right until some tests are written...

[coretl]

To clarify, the code in the original ticket is an idea, but has never been run or tests. It is expected that it is wrong in some way, and writing tests to exercise it will reveal how it is wrong...

[stan-dot]

do we want to add 'skip device' to the factory too?

we could have just one decorator

[coretl]

do we want to add 'skip device' to the factory too?

we could have just one decorator

This is a question for @callumforrester and @DominicOram. I don't know what a skipped device actually is? If we have a decorator here, then maybe we could "skip" it by omitting the decorator?

[DominicOram]

skip was designed to let you provide logic on when to not instantiate a device. This is useful for:

• Running the i03 devices against s03, where not all the devices are simulated
• Running the i03 devices from a workstation, where we do not have PVA access to the beamline

[stan-dot]

it's an architectural question. We can have all the logic that belongs to 'making device class instances' inside a bunch of nested decorators that need to be in right order. OR we can have 1 factory class that accepts a dictionary of features (lazy, mock, skip, directory provicder, post-create script) in one place.

[coretl]

it's an architectural question. We can have all the logic that belongs to 'making device class instances' inside a bunch of nested decorators that need to be in right order. OR we can have 1 factory class that accepts a dictionary of features (lazy, mock, skip, directory provicder, post-create script) in one place.

I have a weak preference for a single decorator, but defer to @callumforrester and @DominicOram for a decision

[DominicOram]

Single decorator works for me.

[stan-dot]

ok I'll prepare a proof of concept for a single decorator device_factory with some (hopefully) sensible default args so that we can put the least props every time.

[stan-dot]

@coretl please checkout the stuff in here

[stan-dot]

device_factory = cast(Callable[..., T], make_fake_device(device_factory))

beamline_utils.py 180

but that is inside ophyd, not sure how it works for ophyd-async

[stan-dot]

tests/common/beamlines/test_device_instantiation.py::test_devices_are_identical[p38] PASSED [  8%]
tests/common/beamlines/test_device_instantiation.py::test_devices_are_identical[i20_1] PASSED [  8%]
tests/common/beamlines/test_device_instantiation.py::test_devices_are_identical[p99] PASSED [  8%]
tests/common/beamlines/test_device_instantiation.py::test_devices_are_identical[i03] PASSED [  8%]
tests/common/beamlines/test_device_instantiation.py::test_devices_are_identical[p45] PASSED [  9%]
tests/common/beamlines/test_device_instantiation.py::test_devices_are_identical[i04_1] PASSED [  9%]
tests/common/beamlines/test_device_instantiation.py::test_devices_are_identical[i04] PASSED [  9%]
tests/common/beamlines/test_device_instantiation.py::test_devices_are_identical[i23] PASSED [  9%]
tests/common/beamlines/test_device_instantiation.py::test_devices_are_identical[i13_1] PASSED [  9%]

the test_devices_are_identical test takes forever to run. is this expected behavior or have I made something wrong, @coretl ?

[stan-dot]

I think I did some stuff wrong, that some tests were awaiting to connect. those tests exit early now for i22