-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add deprecation warning to inject #854
Merged
+73
−0
Merged
Changes from 4 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
057f098
Add deprecation warning to inject
callumforrester 5202cc5
Handle inject deprecation in tests
callumforrester 3c062fd
Fix example in deprecation warning
callumforrester d0be5e3
Draft page about including devices in plans
callumforrester 72efab2
Remove docs that encourage instantiating devices in the middle of plans
callumforrester cd50d73
Fix coverage
callumforrester File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,60 @@ | ||
# Include Devices in Plans | ||
|
||
There are three main ways to include dodal devices in plans | ||
|
||
## 1. Pass as Argument | ||
|
||
```python | ||
import bluesky.plans as bp | ||
|
||
from bluesky.protocols import Readable | ||
from bluesky.utils import MsgGenerator | ||
from dodal.beamlines import i22 | ||
|
||
def my_plan(detector: Readable) -> MsgGenerator: | ||
yield from bp.count([detector]) | ||
|
||
RE(my_plan(i22.saxs())) | ||
``` | ||
|
||
This is useful for generic plans that can run on a variety of devices and are not designed with any specific device in mind. | ||
|
||
## 2. Pass as Default Argument | ||
|
||
```python | ||
import bluesky.plans as bp | ||
|
||
from bluesky.protocols import Readable | ||
from bluesky.utils import MsgGenerator | ||
from dodal.beamlines import i22 | ||
|
||
def my_plan(detector: Readable = i22.saxs(connect_immediately=False)) -> MsgGenerator: | ||
yield from bp.count([detector]) | ||
|
||
RE(my_plan())) | ||
``` | ||
|
||
This is useful for plans that will usually, but not exclusively, use the same device. | ||
|
||
## 3. Instantiate Within the Plan | ||
|
||
```python | ||
import bluesky.plans as bp | ||
import ophyd_async.plan_stubs as ops | ||
|
||
from bluesky.protocols import Readable | ||
from bluesky.utils import MsgGenerator | ||
from dodal.beamlines import i22 | ||
|
||
def my_plan() -> MsgGenerator: | ||
detector = i22.saxs(connect_immediately=False) | ||
# We need to connect via the stub instead of directly | ||
# so that the RunEngine performs the connection in the | ||
# correct event loop | ||
yield from ops.ensure_connected(detector) | ||
yield from bp.count([detector]) | ||
|
||
RE(my_plan())) | ||
``` | ||
|
||
This is useful for plans that are designed to only ever work with a specific device. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't want to encourage this, I want to always have the device as a default argument.
This prevents any metrics/tracing/logging/documenting on the arguments of the plan, leads to N different plans that are just using a different device, makes it easier for the scope of the device to be managed incorrectly and cause issues (conditionally instantiating my device as mock/connecting my device?).
I think the Finder in GDA was a mistake that made every momentary decision to use it slightly easier and every subsequent attempt to extract what the hell was going on a lot harder.
I think it's risking making debugging a lot harder for a small benefit in verbosity, so I would like more attention paid to the above and comments about the benefits of doing it that way.
I'm prepared to be told I'm getting in the way of writing plans for this standpoint. I really don't like it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It also means we can call ensure_connected at the top of the plan and fail fast if any device won't be available, rather than after completing the first iteration of the fastest axis: and we can call connect on all of the devices in parallel rather than on each one as we encounter it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest I broadly agree. Dependency injection is a good thing and, in my opinion, having lots of defaulted parameters is not a particularly terrible thing. Maybe we take this out for now and add it later if demand calls for it?