v2

[rwb27]

labthings-fastapi is a ground-up rewrite of python-labthings using FastAPI and Pydantic in place of Flask and Marshmallow. We've previously discussed it becoming labthings v2, and this pull request is to give that notion some visibility.

I am very open to discussion, and I do wonder if it might be clearer to keep the name labthings-fastapi and just move the repo, rather than mess up the git history by pulling in a project that started again from scratch. I've now reached the point where I am going to need to publish to PyPI soon, which forces a decision. Is this going to become labthings==2.0.0-alpha1 or can I release it as labthings-fastapi==0.0.1. I don't have a particularly strong agenda: there are so many breaking changes it will not be helpful to push the new version onto people using labthings already, and I quite like the notion that there's room, in the future, for labthings-flask if we grow to other frameworks.

As a very brief summary of the work done so far on labthings-fastapi, features include:

• Better alignment with the Web of Things standard:
  • Extensions are gone, everything is now a Thing
  • Things are classes, with properties and actions defined exactly once
  • Various improvements to TD generation and validation with pydantic
• Cleaner API
  • Datatypes of action input/outputs and properties are defined with Python type hints
  • Actions are defined exactly once, as a method of a Thing class
  • Properties and actions are declared using decorators (or descriptors if that's preferred)
  • Dependency injection is used to manage relationships between Things and dependency on the server
• Async HTTP handling
  • Starlette (used by FastAPI) can handle requests asynchronously - potential for websockets/events (not used much yet)
  • Thing code is still, for now, threaded. I intend to make it possible to write async things in the future, but don't intend it to become mandatory
• Smaller codebase
  • FastAPI more or less completely eliminates OpenAPI generation code from our codebase
  • Thing Description generation is very much simplified by the new structure (multiple Things instead of one massive Thing with many extensions)
• Extensive testing
  • FastAPI/Starlette have nice test provision, so the vast majority of the codebase is already covered

Work remains to be done on a few things:

• Add documentation on a par with python-labthings
• Simplify the setting-up of a LabThings server (i.e. allow it to be specified with entry points/config file/etc. rather than needing a Python module for each new configuration)
• Fail gracefully when it's not possible to start the server

[rwb27]

I discussed this offline with @julianstirling and have discussed it in the past with @jtc42. My conclusion is that it probably doesn't matter hugely whether labthings-fastapi becomes labthings==2.0.0 or not. But either way, it probably doesn't make sense to crowbar together two unrelated git histories. I'm going to close this MR for now, and I think I'll release a labthings-fastapi package on PyPI. I might, however, move ownership of the labthings-fastapi repos into the labthings organisation to make it more visible.

Once labthings-fastapi has an API that's stabilised, and perhaps a slightly wider userbase, we can revisit whether it should become labthings. But it may be desirable to keep the fastapi suffix, in case we end up working with multiple back-ends in the future. At that point, if a Flask 2 version appears, we might call it labthings-flask, for example.