@EmsArnold

Codecov Report

❌ Patch coverage is 89.56522% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.69%. Comparing base (d8a989c) to head (266aaa0).
⚠️ Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main    #1284      +/-   ##
==========================================
- Coverage   94.92%   94.69%   -0.23%     
==========================================
  Files          42       43       +1     
  Lines        2717     2828     +111     
==========================================
+ Hits         2579     2678      +99     
- Misses        138      150      +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@abbiemery @DominicOram @EmsArnold @olliesilvester @Relm-Arrowny @oliwenmandiamond @noemifrisina

I have a feeling this may be controversial, so I would like opinions on this. This has been extremely useful for saxs-bluesky and IMO it means we have something closer to a minimum viable Domain-Specific Language (DSL)

There's definitely a need for this sort of thing. How have scientists/users been using this so far, and is there feedback?

I've experimented with similar things using ipython and jupyter notebooks, but it's hard to make it not clunky

Scientists have been experimenting with this on i22 and @EmsArnold has used this. I'd say feedback has been broadly positive. The only complaint i've had is the clunkiness of having to put client.run() to execute a plan via blueapi.

Good to know, I'm a fan of this. I wonder if users would prefer to do this sort of thing in jupyter notebooks or just in a basic terminal. I guess it works fine for both anyway.

Maybe this can be a topic for the next athena drop-in, we can work out the best API + features for this

Not sure this is controversial, blueapi as it is, is very hard to use to run any experiment and this make it much easier.

Kind of related, we run a jupiter server on p99-k8s with an "option" of using the nexus writer for scientist to play with, it may be of interest. This is the startup I gave scientist https://github.com/DiamondLightSource/sm-bluesky/blob/main/demo/p99/stomp_setup.ipynb. You can play with it here: http://172.23.177.194:8888/lab/tree/work it is password protected, I can dm you the password if needed.

We all trying to found ways to make it easier.... may be it is time we try to come up with something we all use?

Good to know, I'm a fan of this. I wonder if users would prefer to do this sort of thing in jupyter notebooks or just in a basic terminal. I guess it works fine for both anyway.

Maybe this can be a topic for the next athena drop-in, we can work out the best API + features for this

Sounds good!

I would find this useful as well. At some point I came up with some functions to wrap Blueapi calls to do something very similar, so having a common standard solution to this problem wouild be good. My current method for testing Blueapi with real hardware on a beamline is fire up GDA and use the Jython console!