Allow BlueAPI to intepret classmethods/staticmethods and/or . in plan name

[RJCD-Diamond]

I would like the BlueAPI to handle dots when parsing bluesky plans. So that I can access plans that are contained within classes ie:

class Johnny5():

    robot: NOVARobot = inject("Johnny5")

    @classmethod
    def self_destruct(self) -> MsgGenerator:
        
        yield from abs_set(self.robot.primed, True)
        yield from trigger(self.robot.detonate)


    @classmethod
    def wave_arm(self) -> MsgGenerator:
        
        yield from abs_set(self.robot.arm, 0)
        yield from abs_set(self.robot.arm, 10)

such that in the jython terminal I can do something like

run_plan("Johnny5.self_destruct")

[DiamondJoseph]

I believe the official supported way to do this is with a Device that returns a plan from its prepare method:

class MyDevice(Device, Preparable[P]):
    def prepare(self, p: P) -> MsgGenerator:
        yield from []

Is there a reason you want to run_plan("Johnny5.self_destruct") vs. just run_plan("self_destruct")? With the example you've given, you'd end up with an exception: you have a classmethod that you're passing the class in as self (allowed but unexpected), presumably you want an instance of Johnny5 being passed in, which means it can't be a classmethod?

[DiamondJoseph]

Or just

def self_destruct(robot: NOVARobot = inject("Johnny5")) -> MsgGenerator:
        yield from abs_set(robot.primed, True)
        yield from trigger(robot.detonate)

def wave_arm(robot: NOVARobot = inject("Johnny5")) -> MsgGenerator:        
        yield from abs_set(robot.arm, 0)
        yield from abs_set(robot.arm, 10)

[RJCD-Diamond]

The reason for doing it that if you bundle all of the plans that only concern one device that you can easily see what your device can do, and you can start writing scripts using these as building blocks. It doesn't stop you making plans that use multiple, but it does simplify the process a whole lot, and make seeing the basic functionality of a device very clear IMO.

These are classmethods so Johnny5.self_destruct() is valid. Why would these throw an exception?

I don't want to pass anything at these high level plans as they should take as few inputs as possible and everything be abstracted away from the beamline scientist/user.

This also keeps familiarity with existing plans, and if the switch is easy, it will get used more often

[DiamondJoseph]

You can write plans that concern a particular device in a module, which keeps them together but separate from other plans:

plans/
  __init__.py
  robot/
    __init__.py
    greeting.py
    exploding.py
  spinner/
    __init__.py
    clockwise.py
    widdershins.py

Then your blueapi config just looks like

      sources:
      - kind: planFunctions
        module: plans.robot.greeting  # Do not expose exploding_plans on this instrument!
      - kind: planFunctions
        module: plans.spinner

With regards to defaulting arguments vs. never exposing them: I'm in the camp of defaulting arguments but allowing them to be overwritten if it's necessary. With the example plan:

def wave_arm(robot: NOVARobot = inject("Johnny5")) -> MsgGenerator:        
        yield from abs_set(robot.arm, 0)
        yield from abs_set(robot.arm, 10)

You can run this plan without passing any arguments: run_plan(wave_arm, {}) and it will inject the default NOVARobot. If you find later that you really actually did want to swap robots, for testing out a new device or similar, you don't need to rewrite your plan. Your UI can choose how to display it, but the default JSON forms (if you only have 1 NOVARobot in the context) would generate a radio button or drop down box with a single option, which is a sanity check I think without being too much extra confusion?

I'm really trying to resist anything that reinvents the Finder from GDA- I think knowing for certain what is being passed into a plan at the top of the plan is going to be really useful for debugging. We can immediately log or trace what is passed in, and put it in the metadata of the Run for analysis. We don't fetch a device halfway down the plan and find that it hasn't been instantiated or connected until now.