Drop FPS in favor of Asphalt

[davidbrochart]

Asphalt (and asphalt-web) provides everything that we tried to do with FPS:

• a system allowing to compose a FastAPI-based web server with plugins,
• a configuration system,
• a logging system,
• a CLI.

Asphalt is also an async framework, which is very useful for web applications (or anything network-related). It has a notion of components that share resources through a context, and can be wired hierarchically to build complex systems.
But I think the most important thing for Jupyverse is the injection system, where a component can request a resource of a certain type, provided by another component. This abstraction layer allows to specify an API for a resource, and have different implementations of it. This solves an important issue that we had with FPS, where plugins directly depended on each other. Now we can easily swap a service with another one, provided that it conforms to a specification.
Since types play such an important role in this architecture, we can really take advantage of them and use e.g. mypy to check the integrity of our system, before running it. I found that this was made harder with FastAPI's own injection system, though.

In development mode, launch the server with:

hatch run dev.jupyterlab:asphalt run config.yaml

[jtpio]

Curious about this and the context for this decision.

Are you dropping FPS because it's not maintained? Or too much work to maintain? Or because Asphalt is a better choice? Or other reasons?

[davidbrochart]

I will update the top comment, but the main reason for switching to Asphalt is that it gives us a better abstraction on top of pluggins. With FPS, pluggins would directly depend on each others, thus the dependency system was basically the packaging. But with Asphalt we have APIs for what pluggins should be. Then it's very easy to swap a pluggin (which is just an implementation of an API) with another one, as long as they respect the same API. I think it's much closer to what JupyterLab has.
Asphalt is a very well designed library, with dependency injection, async support, a configuration system, a signaling system, etc. The next version will be based on AnyIO, which I also like. Also, it opens up new possibilities, such as extending Jupyverse with things that are not just web applications.

[davidbrochart]

This PR is now ready for review.
Tests fail because jupyverse-api has not been released on PyPI yet.

[trungleduc]

Thanks @davidbrochart, Asphalt is really great.