Adapt to FastAPI changes

[rwb27]

This changes type declarations of AsyncGenerator to explicitly include None for the send type. This is required by recent FastAPI versions, which fail with a confusing error if dependencies are typed as AsyncGenerator[<whatever>]. The fix is very simple: explicitly specify AsyncGenerator[<whatever>, None].

The standard library docs suggest either form is equivalent, but clearly there's an implementation detail in FastAPI somewhere that disagrees.

In doing this, I have run into some issues updating dev-requirements.txt for all supported Python versions. I'm going to try to fix that in a separate PR, as it's clear it requires more thought than I have given it here. For now, I will leave the pinned dependencies alone: this PR only fixes the FastAPI problem.

As part of this, I've upgraded the pinned dependencies used in the tests. I couldn't come up with a set of pinned dependencies that works for all Python versions we currently support (3.10-3.13). I have dropped 3.10 from the main test job, and will now pin dependencies on 3.11.

Python 3.10 is still supported, and will continue to be tested without pinned dependencies, until we decide to drop support for it. This feels like a reasonable compromise: I don't intend to release without tests passing on 3.10, but I also don't want to hold up development with painful dependency management.

[rwb27]

Note to reviewers: either of you is sufficient. This does not need double review!

[julianstirling]

Sorry I wrote this a couple of hours ago but failed to submit it.

[julianstirling]

I'm happy with the code changes but we need to get test passing first

[bprobert97]

Happy with the code changes - need to get the test passing

[julianstirling]

It seems #216 is dying because sphinx-autoapi has different dependencies depending on the version. Adjusting our production environment for the sake of the tests seems like it would be the tail wagging the dog.

I still don't really understand the logic of pinned dependency tests as a concept, as we need the tests to pass for any version we support. But it seems that only the python version they were created from would be guaranteed to work?

[rwb27]

Urgh, this is more of a mess than I thought. I will have a think about the nicest way to keep everything working.

I believe I've fixed the only actual problem (that FastAPI gets confused by AsyncGenerator with only one subscript) but by re-pinning the dependencies I seem to have opened a can of worms. Maybe I should get rid of the update, and have this PR just fix the problem with FastAPI. I can then update the pinned dependencies (and CI, if needed) in a separate PR.

[rwb27]

I still don't really understand the logic of pinned dependency tests as a concept, as we need the tests to pass for any version we support.

My motivation is to make the best use of limited developer resources by ensuring we don't need to hit a moving target with every PR. Pinning the environment for testing means that updates to upstream packages won't cause test failures that need fixing during a PR: the PR can concentrate on adding a feature or fixing a bug, and once it's done it can be merged.

Testing with unpinned dependencies is helpful because it catches problems that arise due to upstream updates - but if that happens when there is an open pull request, we then can't merge until the problem is fixed and the fix is rebased into the feature branch.

My compromise was to do both: test with pinned dependencies (and don't merge unless that passes) but also test with unpinned dependencies. I am not sure I ever wrote it down, but my intention was that it should be OK to merge so long as the pinned tests work: if the unpinned tests fail, we will need to log an issue and fix it, but that can be done in a future PR.

Accepting that LabThings is not currently replete with developer hours, I think this is a pretty good solution for ensuring that we catch problems, without interrupting development every time something comes up. Clearly we shouldn't make a release if the unpinned tests are failing: perhaps that could even be written into the CI somehow?

With all of that said, clearly I do need to get all the tests passing here! It may be that I need to be less eager about updating the pinned dependencies, or perhaps even just restrict pinned dependencies to one Python version.

[barecheck]

Barecheck - Code coverage report

Total: 95.01%

Your code coverage diff: 0.00% ▴

Uncovered files and lines

File	Lines
src/labthings_fastapi/outputs/blob.py	369, 455, 574, 660
src/labthings_fastapi/server/__init__.py	167, 303, 317

[julianstirling]

Thanks. It would be good to understand why the changes to FastAPI caused this just for our own knowledge. But clearly this is the needed fix.