Add pytest-split and pytest-xdist

[pvandyken]

pytests-xdist allows multi-core parallelism on tests. pytest-split splits our tests into equally timed folds so that we can run everything across multiple workers. Hopefully the end result is a drastic increase decrease (5-10 fold) in our test timings

[kaitj]

This one largely looks good to me, with one comment on the actions (can leave for a separate PR). With the test splitting, it looks like it is setting up the environment for each python version + split combination. Would need to be tested, but could consider adding a new step after quality and before testing that sets up and caches the environment for each python version.

EDIT: On a second look, could also set up all of the python versions once before quality is run - looks like py3.11 was the only one that didn't need to be set up again. Also makes sense since this was the version used in the quality step.

[tkkuehn]

LGTM

[pvandyken]

@kaitj I setup up your precaching and took the opportunity to simplify some of the workflow. I'm now using the venv caching provided natively by setup-python which seems to work well (the only "weird" thing is that you need to install poetry before setup python, but that doesn't actually cause any real problems). I also cache the poetry install now, which saves a bit of time. Since this is more than a simple edit, I'm refreshing the review request

[kaitj]

This lgtm! That is weird about the poetry / python order.

[pvandyken]

This lgtm! That is weird about the poetry / python order.

The reason is because setup-python uses the poetry executable to figure out where dependencies are being installed so that it can set the cache path. So it's a perfectly rational explanation, just weird if you're looking at the workflow without knowing that

[tkkuehn]

Looks good to me, with the (not new) note that it would eventually be nice to package the "Clone repo" through "Install dependencies" that get reused with minor differences into some reusable package

[pvandyken]

Looks good to me, with the (not new) note that it would eventually be nice to package the "Clone repo" through "Install dependencies" that get reused with minor differences into some reusable package

@kaitj, what repository are you building your reusable github actions in?

[kaitj]

I have been building them here just so that they are centralized, following an entity-value naming scheme, but open to changes. Also with release tags, so that downstream workflows can call a specific version.