DiamondLightSource / DiamondLightSource/dodal
Allow HasName to be used with DeviceManager
- Dominant language
- Python
- Stars
- 5
- Forks
- 13
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 10
Description
In https://github.com/DiamondLightSource/dodal/pull/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 https://github.com/DiamondLightSource/blueapi/issues/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:
```Python
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
```Python
@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...?)
Contributor guide
Assessment
This issue has not been assessed yet.