ENH: Elog poster for ophyd objects and lists thereof

[tangkong]

Description

Added a function (and helper function) for gathering up ophyd objects and posting them to the elog.
Recursively walks through an iterable of devices and formats their .status() output into collapsible blocks.

Motivation and Context

Jira ticket

Hopefully this will provide another way for scientists to log their beamline state.

With the new biological_parents attribute of GroupDevices, we can post entire namespaces without cluttering the post with child devices

How Has This Been Tested?

Interactively, sample posts using devices in xcs hutch python, a few tests have been added to test_utils.py pcds-5.3.0

Where Has This Been Documented?

Docstrings, which have some example code

Pre-merge checklist

• [x] Code works interactively
• [x] Code contains descriptive docstrings, including context and API
• [x] New/changed functions and methods are covered in the test suite where possible
• [x] Test suite passes locally
• [ ] Test suite passes on travis
• [x] Ran docs/pre-release-notes.sh and created a pre-release documentation page
• [x] Pre-release docs include context, functional descriptions, and contributors as appropriate

[ZLLentz]

I like how this looks

[tangkong]

pretty sure this failure is due to travis not picking up the most recent pcdsdevices.devices.GroupDevices PR.

[tangkong]

The interface is a bit unwieldy from the user perspective, there are a lot of arguments to pass for a convenience interface. I feel like this will probably be wrapped on a per-experiment basis, e.g. they'll have a wrapped x.post_elog_status() method with some pre-selected useful devices.

I'm all for simplifying the interface, but I'm not sure how to find the elog other than from xxx.db import elog. I guess registering and retrieving the elog is something to look into now.

Does this belong in nabs? I think if it was in pcdsutils or pcdsdevices we could include it on our device interface too, e.g. we could implement im2k0.post_elog_status().

I like this idea, I'm looking into it now.

[klauer]

Does this belong in nabs? I think if it was in pcdsutils or pcdsdevices we could include it on our device interface too, e.g. we could implement im2k0.post_elog_status().

That's a neat idea! As to where: nabs does have a pcdsdevices dependency and not the other way around (mainly confirming that for myself). Either pcdsdevices or pcdsutils seems fine.

[ZLLentz]

I think it's ok if the elog is created and registered some time in the hutch-python sphere, so long as we've identified a method for registering it.

The raw methods here as laid out by you don't need to be simplified, they span the full set of things we want to do here, but I think there are numerous ways we can wrap them up nicely for the user.

[tangkong]

Moving this to pcdsdevices