Recreate SRO Liver Function Testing key measure with Streamlit

[iaindillingham]

@alarthast and I worked together on this solution to recreate the SRO Liver Function Testing key measure with Streamlit.

Alice, I'd like to highlight the architecture of the solution. app/sro_key_measures.py is the presentation (application) layer; it constructs the user interface. app/measures.yaml is, very loosely, the persistent storage (database) layer. Sitting between the two is a repository (OSJobsRepository), which constructs domain model objects (Measure) using information from the persistent storage layer and passes them to the presentation layer. You can find out more about layers, repositories, and domain model objects in Chapters 1 and 2 of Architecture Patterns with Python.

I'm still learning about layers, repositories, and domain model objects myself, so we shouldn't assume that the solution is the only solution 🙂. However, I think that a well-defined architecture is going to help us iterate quickly.

You many have noticed the following:

open-pathology/justfile

Line 67 in aceb486

PYTHONPATH=. {{ STREAMLIT }} run {{ args }}

Streamlit Community Cloud seems to set PYTHONPATH to the directory within which the "main file" is located, which in this case is app/sro_key_measures.py. However, it's more convenient for PYTHONPATH to be the project root directory. Imports are then relative to the project root directory...

open-pathology/app/sro_key_measures.py

Line 3 in aceb486

from app import measures

...which makes interacting with code in a REPL, such as IPython, less faffy. However, when we deploy the app, we must remember to set PYTHONPATH. It looks like the mechanism for doing so is the same as that for managing secrets.

You asked why I decided not to nest the various URLs in app/measures.yaml. That is, why this...

- name:
  codelist_url:
  counts_table_url:
  top_5_codes_table_url:
  deciles_table_url:

...rather than this...

- name:
  urls:
    codelist:
    counts_table:
    top_5_codes_table:
    deciles_table:

I took the Zen of Python's advice that "Flat is better than nested." (import this). Thinking about it more, though, I don't think there's any reason why these URLs need to be grouped: We don't, for example, group strings or integers; or OS Jobs URLs and OpenCodelists URLs. So, I decided not to nest the various URLs. The flat structure of each record in app/measures.yaml is also consistent with the flat structure of Measure.

Closes #2