Conversation
|
@dmgav any thoughts on this PR? |
|
I was thinking about this idea. I am not against merging the PR, but is there a use case for this? I always thought happi was intended primarily for Ophyd objects. |
|
I'm weakly in favor of this, but I think that the happi dependency should be put in an extra dependency flag rather than being a hard dependency. Should probably also be in a public module? |
|
Just FYI when I actually glanced at this last night I noticed that I totally forgot to add the actual entry points. So please don't merge until I do that. I should probably also add tests so that we know the idea actually works.
I think about Happi as a "configuration file" for any objects that can be instantiated with serializable parameters. We have other mechanisms for recognizing which of those are devices.
I'll think about this. The way I'm personally used to using Happi I don't ever dig down and make items by hand using Python. But I haven't really played with this workflow. I'm hearing "we're okay adding this" so please give me a moment to actually implement something that works practically. |
This is my dream, to use Happi as the one true reference for trucking configuration to the queueserver and back. |
Description
Adding happi support for REManagerAPI objects.
Motivation and Context
End users can find it cumbersome to manually create REManagerAPI objects due to esoteric (to them) arguments. Happi allows them to grab such objects quickly. Happi is familiar to users who are already using it for device management.
Summary of Changes for Release Notes
Added
How Has This Been Tested?
No tests.