Improve bluesky prompt

[awalter-bnl]

@mrakitin and I are suggesting to follow the bluesky prompt change done in https://github.com/NSLS-II-SRX/ipython_ophyd/blob/f3a78c6471544a839676d1067d4574ad4c1b8426/profile_xf05id1/startup/00-startup.py#L82-L90

This change is purely aesthetic, but probalbly worth adding to configure_base()

[danielballan]

I have very mixed feelings about this because it brands IPython as "bluesky" rather than "just an IPython session into which you have imported a module named bluesky which is just like any other module".

[tacaswell]

I have a similar feeling, I am not super happy that we use bsui instead of ipython --profile=collection as well...

[awalter-bnl]

For all but the most programming savvy users on the floor that distinction is lost anyway. Most do not understand the distinction between bluesky, ophyd or ipython. But as this is purely aesthetic I am happy to close this issue. @jrmlhermitte what are your thoughts (as we discussed this together).

[mrakitin]

We can have a HUGE disclaimer that this is not a new CLI, but IPython with imports. The prompt is convenient to understand which beamline we are at, especially for people frequently drifting between beamlines like us. Also, we may add a machine name to the prompt, it frequently matters.

[awalter-bnl]

Sorry I meant to type @mrakitin before not @jrmlhermitte .

Perhaps to get around the issue we can go from: BLUESKY@XXX to: IPYTHON-BLUESKY@XXX

which makes it clear that it is ipython with a bluesky module?

[jrmlhermitte]

I agree with @danielballan . But I like the idea of (no 'bluesky' in it)

SRX@xf05d-ws2:xf05id In [1]:

This would help us know where issues come from from simple copy and paste, or screenshots. (ex: a remote log in terminal running on a different machine etc.)

[awalter-bnl]

I am also happy with @jrmlhermitte suggestion although I don't think the xf........ needs to be repeated twice. Also I think the Ipython-Bluesky prefix explicity covers the point that @danielballan made, as it indicates that this is ipython with a bluesky module. As I mentioned I don't think very many beamline staff (and less users) grasp this fully at present so this is a way of putting it in front of their face every time they use the system.

So perhaps something like: Ipython-Bluesky@SRX:xf05id-ws2 This then follows the convention: Ipython-Bluesky@'beamline initials':'workstation'

I think this then covers two points:

• it helps disseminate the point that bluesky is just an ipython module.
• it helps with support staff who travel around multiple beamlines to get useful information immediately about where they are running.

[danielballan]

I am becoming persuaded that some kind of prompt hacking could be useful, but I think I still have some quibbles about which problems we are trying to solve.

I think the welcome message that bsui spews out at the top helps orient people, and I would rather conserve the characters in the prompt to report information that changes over time (prompt number, timestamp, current git branch, current environment). For example, this is my bash prompt:

(dd) ✔ ~/Documents/Repos/bluesky [fix-typo-in-flyer-asset-collection L|⚑ 8]
08:22 $

Should we brianstorm what kinds of things we might put in the prompt? I'll include all options, even the ones I am arguing against, for completeness:

• [ ] an application label (IPython, bluesky)
• [ ] beamline acronym
• [ ] workstation hostname
• [ ] current username
• [ ] current active IPython profile
• [ ] current conda environment
• [ ] HH:MM timestamp
• [ ] prompt number

I personally would skip the beamline acronym because I can't remember being confused about which beamline a bug report originated from. The specific workstation would occasionally be useful to have, and obviously also implies which beamline (admittedly less prettily).

Other ideas for this list?

[mrakitin]

Taking into account a growing number of parameters to display at the same time, my choices are:

• [ ] an application label (IPython, bluesky)
• [ ] beamline acronym (covered by the workstation hostname)
• [x] workstation hostname
• [x] current username
• [ ] current active IPython profile (not 100% sure about it, seems useful, but a bit lengthy)
• [ ] current conda environment (not 100% sure about it, seems useful, but a bit lengthy)
• [x] HH:MM timestamp
• [x] prompt number

The unchecked boxes can be covered in the header.

[awalter-bnl]

I am happy with @mrakitin's suggestions but don't see the need to add an HH:MM timestamp.

I agree with @danielballan that current Ipython profile and conda enviroment are to lengthy and will cause more issues than they resolve.

I am still partial to having application labels, to highlight Ipython and bluesky use to users, but will follow the group if it is decided it isn't necessary.

[danielballan]

Teddy from SLAC showed me some of their software related to managing beamline setup code and logging. (They don't use IPython profiles.) There a couple ideas worth imitating, and one is automatically logging everything into timestamped files that they can go back and check against any reported problems from beamlines. They capture line of input typed into IPython; they capture the log messages produced by ophyd objects; etc.

If we do something similar, that gives us another place to put some of this information other than the prompt. I suspect we'll still have to argue about which things to put in the prompt, but what doesn't end up there can go in the logs, so we'll have it somewhere.

[awalter-bnl]

This sounds like a really great idea, and will help A LOT with debugging.

[jrmlhermitte]

I agree and like this too. One thing I worry about the prompt is at some point one scientist will decide "hey it's tweakable, why don't I customize it further?" The logs on the other hand would provide systematic untamperable information

[danielballan]

Yeah. I think we want DAMA-controlled logs. As far as prompts go, I think BL staff should customize it to their liking. (CSX, for examples, puts a HH:MM timestamp in the prompt.)

[mrakitin]

@bruceravel showed his custom prompt. See https://github.com/NSLS-II-BMM/profile_collection/blob/5be4bf12c3fcb197ed4be6e61af783a49ef60f1e/startup/98-user.py#L6-L30 for details.

[bruceravel]

Just to comment on the prompt I came up with and from the BL scientist perspective....

I used almost none of Maksim's suggestions from June 1. My prompt has the beamline TLA, a 5 to 7 character string identifying the photon delivery mode, a 3-character colored string indicting the open/close state of the shutters, the ring current, and the normal prompt number in brackets.

That is, I am using the custom prompt to tell me something about the beamline status (rather than the conda/ipython/blusesky environment). The prompt is not a perfect place to do all that, but it is certainly helpful to me.

[tacaswell]

One concern I have about using the prompt to report status is that it reports the status the last time the prompt was generated (which could have been hours ago!) not the status now. While convenient, it seems like it could lead to poor decisions due to outdated information.

I am also a bit concerned with doing epics calls as part of generating the prompt, what happens if one of the IOCs you are hitting goes down?

[bruceravel]

First point is a good point. Hitting carriage return (or even down arrow) updates it. So far it seems more useful than not. But it is certainly a flawed solution.

Second point: have to confess I hadn't thought of that. I'll let you know....