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): add Pydantic models for liquid class schema #16459

Merged
merged 8 commits into from
Oct 14, 2024

Conversation

jbleon95
Copy link
Contributor

Overview

Closes AUTH-834.

This PR follows #16267 and implements the schema as shared data Pydantic models for usage in other parts of the codebase. The models follow the schema in a straightforward matter, the only extra parts that needed to be added were custom validators for the params portion of the different liquid handling properties. If the params are None but enable is set to True, it will raise a validation error.

Test Plan and Hands on Testing

Testing is covered by the unit test added which is able to successfully load the example fixture as the Pydantic model.

Changelog

  • Added liquid_class folder to Python section of shared-data
  • Added Pydantic representation of schema

Review requests

Mostly suggestions for names of files, models, and definitely descriptions. Most of the descriptions written are pretty simple and more useful suggestions would be appreciated.

Risk assessment

Low, new shared data code that doesn't touch anything else.

@jbleon95 jbleon95 requested review from sanni-t and ncdiehl11 October 10, 2024 18:11
@jbleon95 jbleon95 requested a review from a team as a code owner October 10, 2024 18:11
Copy link

codecov bot commented Oct 10, 2024

Codecov Report

Attention: Patch coverage is 96.89922% with 4 lines in your changes missing coverage. Please review.

Project coverage is 74.72%. Comparing base (5658b8a) to head (cc6f654).
Report is 314 commits behind head on edge.

Files with missing lines Patch % Lines
...red_data/liquid_classes/liquid_class_definition.py 96.89% 4 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@             Coverage Diff             @@
##             edge   #16459       +/-   ##
===========================================
+ Coverage   63.28%   74.72%   +11.44%     
===========================================
  Files         300       42      -258     
  Lines       15786     3118    -12668     
===========================================
- Hits         9990     2330     -7660     
+ Misses       5796      788     -5008     
Flag Coverage Δ
g-code-testing ?
hardware ?
shared-data 74.72% <96.89%> (+1.39%) ⬆️
system-server ?
update-server ?
usb-bridge ?

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

Files with missing lines Coverage Δ
...red_data/liquid_classes/liquid_class_definition.py 96.89% <96.89%> (ø)

... and 264 files with indirect coverage changes

@jbleon95 jbleon95 requested a review from a team as a code owner October 11, 2024 14:16
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.

This is good! I like the strict type checking.
Some minor corrections and suggestions for names and descriptions. And the removal of multi-dispense mix

Comment on lines +52 to +57
class Coordinate(BaseModel):
"""Three-dimensional coordinates."""

x: _Number
y: _Number
z: _Number
Copy link
Member

@sanni-t sanni-t Oct 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use coordinates in a number of models. Wonder if it'll be useful clubbing together shared models of shared data. Just a thought

z: _Number


class DelayArguments(BaseModel):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The schema calls these 'params' while it's 'arguments' here. I think we should use the same thing for both. Was there a particular reason for calling these 'arguments'?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly to avoid confusion with the top level aspirateParams, singleDepenseParams, etc. I'd be open to other ideas as long as they disambiguate them with those.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Valid point. How about calling the top-level ones as aspirateProperties or aspirateArguments and have the 'params' from schema be 'params' like DelayParams, TouchTipParams? That keeps the naming consistent with schema and still keeps the two entities separate.

I've been calling them aspirateProperties, dispenseProperties etc in the API side of things.

"""Shared properties for delay.."""

enable: bool = Field(..., description="Whether delay is enabled.")
params: Optional[DelayArguments] = Field(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related to the earlier comment- This feels a bit awkward that the type of delay's params is DelayArguments and not DelayParams

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.

Thanks for making the changes! LGTM! 🙌

@jbleon95 jbleon95 merged commit 6f53924 into edge Oct 14, 2024
46 checks passed
@jbleon95 jbleon95 deleted the liquid_class_shared_data_python branch October 14, 2024 15:43
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.

2 participants