feat(shared-data): add in-schema versions to liquid class schema and definitions

[jbleon95]

Overview

Closes AUTH-1806

This PR adds a version field to the liquid class schema and the three existing liquid class definitions (plus test fixtures). This also has the side effect of changing the folder structure to match labware definitions, where now each liquid class definition is defined under the /liquid-class/definitions/1/ folder as name/version.json instead of name.json.

In addition to this, a version argument was added to define_liquid_class. This currently defaults at 1, but in the future if and when we have additional liquid class definition versions it should automatically load the latest one for that API version.

Test Plan and Hands on Testing

Unit and integration tests should catch any breaking changes.

Changelog

• add version field to liquid class definitions
• add version argument to define_liquid_class

Review requests

Risk assessment

Low

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 57.75%. Comparing base (9cb676f) to head (780c2d7).
Report is 6 commits behind head on edge.

Additional details and impacted files

@@            Coverage Diff             @@
##             edge   #18401      +/-   ##
==========================================
- Coverage   57.79%   57.75%   -0.04%     
==========================================
  Files        3252     3252              
  Lines      276195   276814     +619     
  Branches    32191    32479     +288     
==========================================
+ Hits       159614   159885     +271     
- Misses     116388   116736     +348     
  Partials      193      193              

Flag	Coverage Δ
protocol-designer	19.36% <100.00%> (+0.13%)	⬆️
step-generation	4.62% <100.00%> (-0.21%)	⬇️

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

Files with missing lines	Coverage Δ
shared-data/js/liquidClasses.ts	100.00% <100.00%> (ø)
...n/opentrons_shared_data/liquid_classes/__init__.py	71.42% <ø> (-6.35%)	⬇️
...red_data/liquid_classes/liquid_class_definition.py	96.50% <ø> (ø)

... and 18 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ncdiehl11]

shared-data/js changes look good

[jerader]

changes make sense to me

[ddcc4]

Ah. So the version numbers will start over from 1 if we ever change the schemaVersion?

[SyntaxColoring]

FYI we're not doing it that way for labware definitions. We're doing it like:

• Schema 2
  • Labware XYZ version 1
  • Labware XYZ version 2
• Schema 3
  • Labware XYZ version 3
  • Labware XYZ version 4

Which I'm pretty sure is what we want. Otherwise it's ambiguous what "labware XYZ version 1" refers to, among other problems.

[jbleon95]

Noted, I can update the doc string so it doesn't imply otherwise

[ddcc4]

Wait, why do we want this?

If the user explicitly wants to load version=456 after loading version=123, are you saying we have to return version=123 no matter what?

[jbleon95]

Ooh I did not look closely enough at this test when I was fixing it. The way I have it now is that if you load say version 1 of a liquid class, and then try loading version 2, we will return version 1 because that's what we have cached. This is obviously not ideal, so I will fix that

[alexjoel42]

@jbleon95 , This isn't inclusive of "no liquid class selected" definitions in PD as well as OT-2 work, right?

[ddcc4]

Nitpick: This is a very descriptive name :) but its length is making the rest of the code hard to read. Would it bad to call it something like self._liquid_class_cache instead?

Oh, one more thing to look into: If you want to be really fancy, I think there are some built-in Python decorators for memo-ization, so that you don't have to write this code yourself.