-
Notifications
You must be signed in to change notification settings - Fork 14
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
Global dummy mode: expected behavior #182
Comments
The main reason for dummy mode was to avoid hanging on to DLLs for the USB instruments (as you enumerated above) when all we wanted to do was scrape the auspex package with quince to create the nodes. Quince would hang on to the DLLs otherwise and cause problems. I never had any intent beyond that — do you think there's a use case beyond the scraping? |
The use case I had in mind was debugging when a fridge is warm and I don't want to actually connect to any instruments. I could always nuke the yaml files or disable all the instruments. It might not be useful to anyone else but I was thinking it would function as a kind of debug mode. |
At the moment, we still need to link the idea of not loading the libraries and creating fake data. Might also be nice to have an option to ignore all plotting for unit test. |
Seems like
auspex_dummy_mode
only affects the Alazar, X6 and APS units. Is this the behavior we should assume or should Auspex not try to connect to anything in 'dummy mode'? I guess I'd vote for the later unless there's a strong reason for limiting this to sequencers and digitizers.Could we just add a check in the base instrument class and use MagicMock if
auspex_dummy_mode
is true? @grahamrow @gribeill @dieris what do you think?The text was updated successfully, but these errors were encountered: