[rwb27]

This PR allows Things to specify that some Thing Slots must be started first. That means the connected Thing will already be running when __enter__ is called on the host Thing. This should make it easier to write code that interacts with other Things on start-up.

The new syntax looks like the example in #388:

import labthings_fastapi as lt
from .other_thing import MyOtherThing

class MyThing(lt.Thing):
    wrapped: MyOtherThing = lt.thing_slot(start_first=True)

    def __enter__(self) -> None:
        # LabThings will have ensured that `self.wrapped` started up before
        # this Thing starts up, i.e. before `__enter__` is called.
        self.wrapped.do_something()

Without start_first=True there is no guarantee that self.wrapped has started up, so the function call in __enter__ may or may not work.

I think, reading my comments back in #388, that deferred=False might be clearer: I feel start_first is ambiguous whether it means start the connected thing first, or start this thing first. I think it's clear that deferred refers to the slot, and so if slots are deferred by default, it means you get no guarantee they've started at the point __enter__ is called.

Things to do before merge:

• Add example code here rather than in Ordered Initialisation of Thing Slots #388
• Consider deferred=False instead of start_first=True to enable this behaviour.
• Add example code in documentation
• Tidy up tests with a common base class
• Make sure dependencies on all things/the current thing get ignored (because that's always circular)

Closes #388

[barecheck]

Barecheck - Code coverage report

Total: 97.39%

Your code coverage diff: -0.03% ▾

Uncovered files and lines

File	Lines
src/labthings_fastapi/server/__init__.py	252, 261, 265, 329, 343-346, 458
src/labthings_fastapi/thing_slots.py	374
src/labthings_fastapi/utilities/__init__.py	123, 144, 158, 190, 198