-
Notifications
You must be signed in to change notification settings - Fork 179
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
feat(shared-data): Support quirks, mount and mutable configs in v2 pipettes #12966
Conversation
Codecov Report
@@ Coverage Diff @@
## edge #12966 +/- ##
==========================================
+ Coverage 72.70% 72.88% +0.18%
==========================================
Files 2367 2380 +13
Lines 64631 66113 +1482
Branches 7261 7753 +492
==========================================
+ Hits 46987 48188 +1201
- Misses 15955 16102 +147
- Partials 1689 1823 +134
Flags with carried forward coverage won't be shown. Click here to find out more.
|
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 think I agree with putting the quirks in code like this. It means if we ever want to add some new model we have to add it in conceptually separate places. If we can drop it in configs then we're back to the same system and I think we're fine.
416d8bc
to
1e4ccd9
Compare
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.
This overall looks, well, like something we have to do, but I really want to avoid duplicating that IS_ROBOT
bool - I think that will eternally bite us if we duplicate it.
shared-data/python/opentrons_shared_data/pipette/file_operation_helpers.py
Outdated
Show resolved
Hide resolved
|
||
# TODO(mc, 2020-09-17): s/fields/setting_fields (?) | ||
# need model and name? |
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.
won't this break without 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.
Not sure which is why I want to test on a robot. I don't know why it would break because the app only deals with the model for this feature.
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.
Can we add it anyway? Regardless of whether it's needed, this is in theory a controlled API and this would represent a change.
overrides: TypeOverrides, | ||
) -> OverrideType: | ||
"""Helper function to add new overrides to the existing ones""" | ||
# FIXME remove the validation here for the file save and rely |
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 guess we can do this by passing down a full pydantic model at this point?
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.
Okaym, I really like the changes to get the base directory passed in and decided elsewhere, the lack of duplication is great. I think the last thing I'd really want to see is fixes to the HTTP API and the tavern tests. Those tests are for detecting regressions, and I think that this PR introduces changes both of value and of kind (not having names) that we really need to investigate and probably fix.
|
||
# TODO(mc, 2020-09-17): s/fields/setting_fields (?) | ||
# need model and name? |
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.
Can we add it anyway? Regardless of whether it's needed, this is in theory a controlled API and this would represent a change.
# Temporarily remove this test. I realized that tavern is not | ||
# actually using the temporary directory path provided by the pytest | ||
# fixtures because it's technically not running in the same environment | ||
# I tried to timebox this and couldn't come up with a good solution. |
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.
What we have done in other cases is make a separate fixture used by tavern. I think we really want this test in before we merge.
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.
So that fixture actually doesn't work across tests. It just so happens to be OK for the other tavern tests even though they are accessing the file system locally.
For this test specifically, the folder it's checking for already has a lot of junk (including pipette serial numbers that would never exist in the folder). I could raise an error in this case, rather than a KeyError, but the test would still fail all the same.
So essentially all of these tavern tests relying on a tmp dir aren't actually doing that. I tried figuring out a way to manipulate the env variable for tavern and couldn't successfully do that. The ultimate problem is that tavern does not see the modifications to the environment variables from pytest fixtures so even though we're adding OT_CONFIG_DIR in the pytest fixture, it doesn't exist at the time of the GET
request.
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.
Awesome! Looks really good
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.
Tested on an OT-2 and confirmed that pipette settings & quirks changes from app are propagated correctly to the settings files on the robot and the app reads file contents correctly. Also verified that all changes are correctly reset to default with 'Reset All'.
Overview
Support mutable configs and smoothie configs with the new v2 pipette schema.
Test Plan
Throw this on an OT-2 robot and mess around with the pipette config settings to make sure everything still renders correctly.
Changelog
The next step after this PR is to port the OT-2 to the new configs and support loading the new configs in the protocol engine.
Review requests
Please check it over and let me know what thoughts you have.
Risk assessment
Medium. Touches core functionality on the OT-2