Demark plan vs stub, move orphaned plans into dodal #793
Conversation
DiamondJoseph
force-pushed
the
move-example-plans
branch
2 times, most recently
from
7ab3c64
to
019b6ed
Compare
DiamondJoseph
force-pushed
the
move-example-plans
branch
from
afaaddf
to
eb7ca4f
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #793 +/- ##
==========================================
+ Coverage 95.63% 95.70% +0.06%
==========================================
Files 128 132 +4
Lines 5271 5326 +55
==========================================
+ Hits 5041 5097 +56
+ Misses 230 229 -1 ☔ View full report in Codecov by Sentry. |
DiamondJoseph
force-pushed
the
move-example-plans
branch
3 times, most recently
from
fddc20d
to
037fe3e
Compare
DiamondJoseph
force-pushed
the
move-example-plans
branch
from
b2963ad
to
32dd6e1
Compare
DiamondJoseph
changed the title
|
|
||
| @attach_data_session_metadata_decorator() | ||
| @validate_call(config={"arbitrary_types_allowed": True}) | ||
| def spec_scan( |
There was a problem hiding this comment.
FYI: I added DiamondLightSource/mx-bluesky#596 as I think we have overlap here
There was a problem hiding this comment.
This plan has now moved repositories so many times that the issue has now been lost to time, but it does need improvement. The axes_to_move parameter was a temporary fix and we should try to get rid of it.
There was a problem hiding this comment.
I think we no longer need axes_to_move, I just need to find time to start up blueapi with these plans and ensure we can run a spec just passing the name of the device and no axes_to_move
There was a problem hiding this comment.
In theory, all plans that use a ScanSpec should be constructing their specific spec and passing it to this (for software scans) or an ophyd-async plan to-be-produced for hardware.
| """Reads from a number of devices. | ||
| Wraps bluesky.plans.count(det, num, delay, md=metadata) exposing only serializable | ||
| parameters and metadata.""" |
There was a problem hiding this comment.
Nit: I assume we've discussed with bluesky to try and get this into the core codebase and couldn't? May be worth a link to that discussion in case anyone asks the question again
There was a problem hiding this comment.
It was a series of mostly offline discussions and should probably be written up as an ADR
There was a problem hiding this comment.
Does someone involved in the discussion have time to write an issue with some back of the envelope bullet point reasons and saying to put them in an ADR, just before it's lost to time?
There was a problem hiding this comment.
I believe we need DiamondLightSource/blueapi#474 for the @attach_metadata to be handled in blueapi consistently, then that decorator gets moved back into blueapi and then blueapi can just use bluesky.plans as a plans module (or... the ones we actually want).
There was a problem hiding this comment.
In which case can we have a comment here saying we can remove this when that has been done?
DiamondJoseph
force-pushed
the
move-example-plans
branch
from
63fd415
to
b7d1257
Compare
| """Reads from a number of devices. | ||
| Wraps bluesky.plans.count(det, num, delay, md=metadata) exposing only serializable | ||
| parameters and metadata.""" |
There was a problem hiding this comment.
In which case can we have a comment here saying we can remove this when that has been done?
| """ | ||
| Bluesky distinguishes between `plans`: complete experimental proceedures, which open and | ||
| close data collection runs, and which may be part of a larger plan that collect data | ||
| multiple times, but may also be run alone to collect data, and `plan_stubs`: which | ||
| do not create & complete data collection runs and are either isolated behaviours or | ||
| building blocks for plans. | ||
|
|
||
| In order to make it clearer when a MsgGenerator can be safely used without considering | ||
| the enclosing run (as opening a run whilst in a run without explicitly passing a RunID | ||
| is likely to cause both runs to fail), when it is required to manage a run and when | ||
| running a procedure will create data documents, we have adopted this standard. | ||
|
|
||
| We further impose other requirements on both plans and stubs exported from these modules | ||
| to enable them to be exposed in UIs in a consistent way: | ||
| - They must have a docstring | ||
| - They must not use variadic arguments (*args, **kwargs) | ||
| - Plans must and Stubs may have an optional argument for metadata, named "metadata" | ||
| - The metadata argument, where present, must be optional with a default of None | ||
| """ |
Bluesky distinguishes between plans: complete experimental proceedures, which open and close data collection runs, which may be part of a larger plan that collect data multiple times, but that might also be run alone to collect data, and plan_stubs: which do not create & complete data collection runs and are either isolated behaviours or building blocks for plans.
In order to make it clearer when a MsgGenerator can be safely used without considering the enclosing run (as opening a run whilst in a run without explicitly passing a RunID is likely to cause both runs to fail), when it is required to manage a run and when running a procedure will create data documents, we should adopt this standard.
This change also adds the count and spec_scan plan previously from dls_bluesky_core, as remove this as a requirement for blueapi is long overdue and this is the last remnants of that module.
countis a basic collection of a set of devices, equivalent to Mapping GDA's StaticScan.spec_scanis analogous to GDA'smscancommand, constructing a generic N-dimensional trajectory for scanning.After these plans have been moved, the default blueapi context can be configured to import as a plans module dodal.plans and dodal.plan_stubs.wrapped: this will only expose those stubs that should be runnable by a user from the client.
Checks for reviewer