In #1798 and through out other beamlines, we have a mix of global state and dependency injection being used for the daq config server config client. The global state is used because in MX, they need access to the config server inside plans independent of devices. DeviceManager and BlueAPI currently only supports the concept of a Device from ophyd-async.
Instead, I'm proposing broadening this restriction to include the Bluesky protocol HasName inside DeviceManager (V2 = TypeVar("V2", bound=OphydV2Device | HasName)) (will also need BlueAPI to support DiamondLightSource/blueapi#1462) so we can make still make a clear distinction between what is a Device and what isn't while also making other objects findable and therefore injectable inside plans and can remove the use of troublesome global states.
For example:
class InjectableConfigClient(HasName):
def __init__(self, url: str, name):
self.client = ConfigClient(url)
self._name = name
@property
def name(self) -> str:
return self._name
...
devices = DeviceManager()
@devices.factory()
def config_client() -> InjectableConfigClient:
return InjectableConfigClient("https://daq-config.diamond.ac.uk", "config_client")Then in a plan repository, we can then do this for example
@plan
def my_plan(config_client: InjectableConfigClient = inject("config_client")) -> MsgGenerator:
config_client.client.reset_cache()This will make plans working with BlueAPI much more flexible.
One thing is that isn't really as much of DeviceManager with this change and I would argue more of BeamlineManager (maybe rename...?)
In #1798 and through out other beamlines, we have a mix of global state and dependency injection being used for the daq config server config client. The global state is used because in MX, they need access to the config server inside plans independent of devices.
DeviceManagerand BlueAPI currently only supports the concept of aDevicefrom ophyd-async.Instead, I'm proposing broadening this restriction to include the Bluesky protocol
HasNameinsideDeviceManager(V2 = TypeVar("V2", bound=OphydV2Device | HasName)) (will also need BlueAPI to support DiamondLightSource/blueapi#1462) so we can make still make a clear distinction between what is a Device and what isn't while also making other objects findable and therefore injectable inside plans and can remove the use of troublesome global states.For example:
Then in a plan repository, we can then do this for example
This will make plans working with BlueAPI much more flexible.
One thing is that isn't really as much of
DeviceManagerwith this change and I would argue more ofBeamlineManager(maybe rename...?)