ophyd new logging framework

[ke-zhang-rd]

Expected Behavior

Control flow on handler level

Current Behavior

Control flow on logger level

Possible Solution

new log.py file copy paster most from caproto log here

Important use cases we want to support

TO DO

List of loggers we need

• ophyd
• ophyd.mixins
• ophyd.pseudopos
• ophyd.pv_positioner
• ophyd.signal
• ophyd.utils.epics_pvs

Agree?

List of extras we need (where applicable)

• TO DO

[danielballan]

I think it might be worth considering breaking down the loggers by their purpose rather than by component type. Something like:

* ophyd  - top-level
* ophyd.staging - staging and unstaging
* ophyd.status - when status objects are created and completed
* ophyd.control_layer - relating to setup/teardown of the control layer
* ophyd.connection - when components connect/disconnect (maybe this is best left to the control layer though?)

Thoughts, anyone?

[awalter-bnl]

I agree with @danielballan, If I think of what happens when we arrive at a beamline usually we know, or can quickly work out, when in the process the issue is occuring (say, during stage of a device, or while moving a device (status object issue), or while connecting to a device).

Working out 'what type' of object is causing issues, as described in the above (i.e. a mixin, or a pseudo_pos, ...) would take a not insignificant amount of extra work.

[mrakitin]

👍 for the approach.