feat(test-data-generation): add ability to generate invalid load statements

[DerekMaggio]

Overview

This PR aims to add the ability to call protocol_context.load_* methods in a way that generates invalid protocols. There is also a whole lot of refactoring that went into this PR to enable these invalid calls. I removed as much as I could to go into a different PR.

Features

2 main features are exposed: explict_loads and allow_overlapping_loads.

explicit_loads

An explicit load is a protocol_context.load_* statement specified outside of the internal load statement generation logic from a Deck Configuration. These are stored as a dictionary
which takes the slot for the key and the load for the value. Also note, that explicit loads have access to column 4 on staging areas

explict_loads = {
    "a3": <a_heater_shaker_load_statement>,
    "c4": <a_trash_bin_load_statement>,
}

allow_overlapping_loads

When defining a protocol, it is invalid to say, "Load the Heater-Shaker in slot C1 and also load a Trash Bin into slot C1. The allow_overlapping_loads` switch, allows a test writer to override this default behavior and specify the loading of multiple things into the same slot.

How to use these new features

There are 2 main ways that you can use explict_loads and allow_overlapping_loads together: explict_loads defined and allow_overlapping_loads set to False and explict_loads defined and allow_overlapping_loads set to True.

When you have allow_overlapping_loads set to False, if you already have a fixture defined in the slot that the explicit load is acting on, the explicit load REPLACES the existing fixture.

When you have allow_overlapping_loads set to True, if you already have a fixture defined in the slot that the explicit load is acting on, the explicit load is APPENDED AFTER the existing fixture.

Usage

• See python_protocol_generation_strategies.py

Changelog

Logic

The implementation of explict_loads exists mainly in, ast_helpers.py and load_phase.py.

ast_helpers.py now has 1-to-1 instantation methods for each of the utilized protocol_content.load_* methods.

load_phase.py

• To remove all isinstance logic, all the helper methods now return lists of assignment statements.
• Add logic for either overriding or appending

Refactors and supporting content

• Rename PossibleSlotContents to DeckConfigurationFixtures - now that explicit loads define things in slots, but don't use this object, rename it to make it clearer
  • Also change the list-generating properties to classmethods, shouldn't have to have an object instantiated to get access to those lists
• Combine all the different datashapes and constants into singular files. I was fighting so many circular imports
• For constants, switch nearly everything over to typing.Literal instead of enum.Enum- cleans up calling logic
• Define ProtocolConfiguration dataclass to hold all these different settings instead of passing 5 arguments to PythonProtocolGenerator
• Note that all the changes in python_protocol_generator don't change any logic. Just usages of classes
• Refactor test/utils.py into protocol_analysis_validator.py. Parsing the output of failed tests sucked, and was making writing them a nightmare. This fixes that.
• All pytest tests now use ProtocolConfiguration objects. No more DeckConfiguration object test cases.
• Add pytest-xdist, these tests are CPU bound so running them in parallel speeds up overall execution. Something to keep in mind as we move forward

Test Plan

• Manually validate various generated protocols
• Manually validate analysis response from the various protocols
• Run ~600 tests per strategy and determine if any failures are due to my generation code or are actual failures. Resolved all the issues, they were all me
• Run new protocols against analysis in app to check for any weirdness

Review requests

• Please take a look at the load statement determination logic
• The logic in python_protocol_generation_strategies.py is quite dense. Any suggestions?

Risk assessment

Low

[sfoster1]

Looks good to me, nice

[caila-marashaj]

very cool!