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

[coretl]

@DominicOram are we thinking that device_factory will be used with ophyd v1 devices? If not, then we should delete this section

[DominicOram]

We will likely have ophyd v1 devices around for a couple more months. If I can mix and match old and new ways of instantiating devices in the same beamline file I'm happy to have device_factory just on the ophyd-async ones. If so I would like a test confirming that mixing them like this works as expected.

[stan-dot]

I had in mind supporting either there

[stan-dot]

todo: make a test if it works with ophyd v1 devices

[stan-dot]

VGonio at i24 is one such device, testing with it

[stan-dot]

it's not a complicated device, could be easily migrated to ophyd_async

[stan-dot]

only that, Eiger and some AreaDetector implementations and some helpers are using the old ophyd imports.

not sure how does the section indicated map to the difference between the two ophyd implementations

[stan-dot]

I literally just added a docstring and the CI started failing. what is going on???

f224a17