Open klauer opened 2 years ago
I think this fully encompasses the considerations/ideas we've discussed so far.
Inheritance
To what level do we want to support this without it becoming too confusing to find out where settings are coming from? Is there a middle ground or is it all-or-nothing?
I think we need to have the loader keep track of all config bits that contributes to an object's fully inherited config, such that we can audit it later, e.g. a list that says "got these config settings from Device, added these from EpicsMotor, overrided the whole thing in IMS"...
Context
There are a certain number of per-
ophyd.Device
configuration settings that users will never be happy with our choice of defaults. While discussing this, our primary example has been device tab whitelists.As different users have different (legitimate) needs and preferences, @ZLLentz and I came to the conclusion that it's sensible for us to:
User-configurable settings
Some potential things that we would add:
device.screen()
)Defaults
Format?
Providing a configuration file of a common format (explicitly not Python code) such as JSON or YAML seems to be superior for the following reasons:
Device classes and instances
Why support classes as well as instances?
EpicsMotor
would be nonsensical (and generate a large config file, at that)Why not just support classes and not instances?
Inheritance?
Questions for now, as this requires more discussion:
ophyd.Kind
specifically - how do you deal with conflicts?ophyd.Component
which has a class/instance configuration, and when the parent device has conflicting class/instance configuration settings?Tooling
We should provide some additional tooling that performs the following:
ophyd.Device
Kind
trees so that the user can tweak them easily