Skip to content
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

Merged
merged 15 commits into from
Jul 11, 2023

Conversation

Laura-Danielle
Copy link
Contributor

@Laura-Danielle Laura-Danielle commented Jun 23, 2023

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.

  • Remove config changes
  • Add a new config change
  • click and un-click quirks.

Changelog

  • Add quirks to schema
  • Add mutable config helpers to shared data
  • Utilize the new mutable configs in the robot server endpoint

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

@codecov
Copy link

codecov bot commented Jun 23, 2023

Codecov Report

Merging #12966 (ce448c4) into edge (d02dc6f) will increase coverage by 0.18%.
The diff coverage is 94.09%.

Impacted file tree graph

@@            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     
Flag Coverage Δ
app 71.51% <ø> (+0.17%) ⬆️
protocol-designer 45.11% <ø> (+1.02%) ⬆️
shared-data 78.32% <94.09%> (+1.93%) ⬆️
step-generation 87.24% <ø> (+2.96%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...ver/robot_server/service/legacy/models/settings.py 98.76% <ø> (-0.05%) ⬇️
...er/robot_server/service/legacy/routers/settings.py 100.00% <ø> (ø)
...ared_data/pipette/pipette_load_name_conversions.py 85.05% <84.61%> (+1.05%) ⬆️
...rons_shared_data/pipette/mutable_configurations.py 91.30% <91.30%> (ø)
...rons_shared_data/pipette/file_operation_helpers.py 95.65% <95.65%> (ø)
...data/python/opentrons_shared_data/pipette/types.py 98.11% <98.11%> (ø)
.../python/opentrons_shared_data/pipette/load_data.py 97.91% <100.00%> (+1.76%) ⬆️
...n/opentrons_shared_data/pipette/model_constants.py 100.00% <100.00%> (ø)
...pentrons_shared_data/pipette/pipette_definition.py 97.08% <100.00%> (+0.18%) ⬆️

... and 81 files with indirect coverage changes

Copy link
Member

@sfoster1 sfoster1 left a 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.

@Laura-Danielle Laura-Danielle marked this pull request as ready for review June 29, 2023 21:55
@Laura-Danielle Laura-Danielle requested a review from a team as a code owner June 29, 2023 21:55
@Laura-Danielle Laura-Danielle requested a review from sfoster1 June 29, 2023 21:55
@Laura-Danielle Laura-Danielle force-pushed the RLIQ-345-mutable-configs branch from 416d8bc to 1e4ccd9 Compare June 30, 2023 07:29
@Laura-Danielle Laura-Danielle requested a review from a team as a code owner June 30, 2023 09:09
Copy link
Member

@sfoster1 sfoster1 left a 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.


# TODO(mc, 2020-09-17): s/fields/setting_fields (?)
# need model and name?
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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
Copy link
Member

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?

Copy link
Member

@sfoster1 sfoster1 left a 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?
Copy link
Member

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.
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

@sfoster1 sfoster1 left a 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

Copy link
Member

@sanni-t sanni-t left a 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'.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants