feat(api): add version argument to protocol context get_liquid_class

[jbleon95]

Overview

Addresses part of AUTH-2246

This PR adds a version argument to the public ProtocolContext.get_liquid_class method. It is an optional argument that defaults to None. If the version argument is included, we will attempt to load that version of the liquid class, failing if that version does not exist. If the version argument is not filled, we will automatically try and load the latest version for the protocol's API level.

This PR adds loading version 2 of water, ethanol_80 and glycerol_50 for API version 2.26. This PR does not add those liquid class definitions nor does it bump up the API level. Those two tasks will be covered in future PRs.

Test Plan and Hands on Testing

This protocol analyzes properly, and covers both explicitly calling with and without a version. Changing the version to a non-existent one causes an error appear.

requirements = {
    "robotType": "Flex",
    "apiLevel": "2.25"
}

metadata = {
    "protocolName":'Liquid Class Loading Regression Test',
}

def run(protocol_context):
    tiprack = protocol_context.load_labware("opentrons_flex_96_tiprack_50ul", "C2")
    trash = protocol_context.load_trash_bin('A3')
    pipette = protocol_context.load_instrument("flex_1channel_50", "left")
    nest_plate = protocol_context.load_labware("nest_96_wellplate_2ml_deep", "D1")
    arma_plate = protocol_context.load_labware("armadillo_96_wellplate_200ul_pcr_full_skirt", "D3")

    water_class = protocol_context.get_liquid_class("water")

    ethanol_class = protocol_context.get_liquid_class("ethanol_80", version=1)

    another_ethanol_class = protocol_context.get_liquid_class("ethanol_80")


    pipette.transfer_with_liquid_class(
        liquid_class=water_class,
        volume=50,
        source=arma_plate.columns()[0][:2],
        dest=nest_plate.columns()[0][:2],
        new_tip="always",
        trash_location=trash,
        tip_racks=[tiprack],
    )

Changelog

• add optional version argument to get_liquid_class
• add a get_liquid_class_version function to determine which liquid class definition version to load when a version is not provided

Review requests

Risk assessment

Low, this PR does not introduce the new liquid class versions and does not change the behavior of existing protocols.

[SyntaxColoring]

Makes sense, thank you!

[ddcc4]

Hm, what's our policy on the core functions vs the public API? Would it be simpler to make the core function always require a version number, and let the public API handle choosing a version number for the user if none is specified?

[jbleon95]

I don't think we have a strong policy, there's an argument that can be made that argument validation and resolving happens in the public API, but I also like stashing away the logic for this in the core implementation where it's less immediately visible. The good thing is we can always change this around since it's not user-facing.

[ecormany]

Docstring is totally fine, so don't hold this up any more on account of me!