Open stashlukj opened 4 years ago
This is for the ophyd repository.
I moved this because the logic for creating a Device lives in ophyd. LiveTable is a callback in bluesky and should not be responsible for catching problem names for Devices.
I don't think we forbid ":"
in the names? I am also not sure how much we want to enforce limits imposed by the EventModel (which is actually imposed by a particular database choice in terms of the '.') down to the ophyd level. It is convenient for or current use cases, but it in not clear to me that we want to constrain other the use of arbitrary names in other contexts.
The problem @stashlukj found with LiveTable was that the name had a ':'
in it, we format a format string which looks like {{{name}:{fmt}}}
which comes out looking like {name:part:d}.format(**{'name:part': value})
which that fails to find the key "name" :facepalm:
ophyd itself doesn't really care about names, as far as I recall. Downstream clients and databases may fail based on their own requirements for column names (for example).
Separately, bluesky does not require ophyd. If a custom, non-ophyd class follows the BlueskyInterface
and has a "bad" name, LiveTable
/databroker/etc will fail just the same.
https://github.com/bluesky/bluesky/pull/1367 fixes this on the bluesky side.
Device names with illegal characters can fail in unexpected ways.
Expected Behavior
LiveTable shows the normal entries.
Current Behavior
The livetable runs, but gives "failed to format row" messages. The document in
db[-1].table()
is still ok looking.Possible Solution
The MyDevice constructor should raise an exception about the dicey ':' and '.' in the name.
Steps to Reproduce (for bugs)
Context
I was trying to debug why I couldn't LivePlot my sensor.
Your Environment
Ubuntu 20.04 in WSL. Python 3.8. bluesky==1.6.2