DiamondLightSource / DiamondLightSource/blueapi
BlueapiClient devices do not know about child devices until after user uses them
- Dominant language
- Python
- Stars
- 13
- Forks
- 13
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 25
Description
`BlueapiClient` asks blueapi server for all available devices and then caches them. This makes it so autocomplete now works on the terminal making it very handy when composing plans on command line. However, blueapi cannot handle child devices.
Very often, a device will hold a group of other devices / signals and need to be accessed to run plans. For example `Motor` stages will have x, y, z motor components. pgm devices have child signals/motors for energy.
So a very basic example would be
```python
plans.set_absolute(pgm.energy, 500)
plans.set_absolute(stage.x, 10)
plans.set_absolute(stage.y, 20)
```
`BlueapiClient` has no idea these child devices of energy, x, and y exist so the user has to guess what is available.
How it works is if it doesn't exist from the cache, the device is requested from the server and then if it exists, it is then added to cache and then autocomplete now works. However, when loading devices, `BlueapiClient` should be aware of all devices on the server, including all child devices of a `Device`, so that automcomplete will work straight away rather than guessing first for all devices.
This is related to https://github.com/DiamondLightSource/dodal/issues/2208 because `DeviceManager` only provides the higher level devices to blueapi and not the device children so it has not concept of the child devices unless asked explicitly to check for it.
This would vastly improve the user experience using the client if you could print the device tree or the device `__repr__` to show it (similiar to a plan `__repr__ ` displays the plan signature) to know what is available to work with and that auto complete for child devices works from the start.
As we are going to have name clashes with device attributes and what blueapi needs, we should probably reserve in dodal device attributes so that they never have a `model` signal / sub device. Similar to how ophyd-async reserves bluesky key words. This could be done inside `DeviceManager`. When it loads in a device, it checks there are no signals / child devices with `model` as an attribute.
Contributor guide
Research direction
Start with the BlueapiClient device-loading and cache path described in the issue, then trace how DeviceManager supplies devices and child devices. Clarify whether the scope includes a device tree or __repr__ and reserved attributes. Done should mean child devices are available to autocomplete immediately after loading, without a prior lookup.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- api, cli, developer-experience
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100