search

bluesky / yaqc-bluesky

A bluesky interface to the yaq instrument control framework.
https://yaq.fyi/
BSD 3-Clause "New" or "Revised" License
8 stars 4 forks source link

Namespace dependent hardware to avoid name collisions #74

Closed ksunden closed 2 years ago

ksunden commented 2 years ago

Not sure I love this change, but something needs to be done.

This will result in some weird things like perhaps "w1_w1_crystal1", but that is perhaps preferable to not being able to record both w1 and w1_crystal1 directly....

untzag commented 2 years ago

It's not my preference, but it mimics what ophyd does right? I guess the greatest good is to not swim against the current on this one.

untzag commented 2 years ago

@ksunden update CHANGELOG and then feel free to self merge

ksunden commented 2 years ago

it mimics what ophyd does right?

ehh... actually old behavior looks more like ophyd... I'm actually going to hold off on merging this as I want to actually think on/discuss it more... its a workaround for something observed in bluesky-in-a-box....

The problem (which may actually be simple to solve now with some of the recent changes to queueserver) is that we have not had until recently subdevices, thus we put everything in at the top level.

Then, because we want a snapshot of our system since info is often otherwise lost, we put all hardware that we know of in the baseline reading.

It is there that names collide as both the parent and the child give the same key for some things... if we only put the parent as a direct listed value, we may do better and be more consistent in the ecosystem... there are a few things I need to look into... mostly wanted this open so I could reference it in bluesky-in-a-box while I use it as a workaround.