Without the pin, poetry downgraded pygtihub from 1.54.1 to 1.53.
Cause of issue: pygithub (1.54.1) depends on pyjwt (<2.0)
Poetry upgrades pyjwt from 1.7.1 to 2.0.1. This causes subsequent downgrade of pygithub to 1.54, but 1.54 is incompatible with requests (>=2.14.0,<2.25). So Poetry downgrades it to 1.53, which does not have the <2.25 constraint.
Dependency injection is cool - it should however not be confined to the top-layer of the application. Inversion of control can help every layer and is a great way to de-couple various parts of the app.
This code brings in a framework (Lagom) to build a dependency injection framework and then adds a small function (``depends``) that adapts it to FastAPI's dependency injection mechanism ("Depends").
The advantages to this approach are numerous.
We don't need to write these little adapters for each component of the backend to adapt it FastAPI. For example look at the change to the roles API controller:
```diff
-def get_role_manager(app: UniverseApplication = Depends(get_app)) -> RoleManager:
- return app.role_manager
-
-
@cbv(router)
class FastAPIRoles:
- role_manager: RoleManager = Depends(get_role_manager)
+ role_manager: RoleManager = depends(RoleManager)
```
This is much less boilerplate. We don't need to implement & type that function get_role_manager and we don't need to bring in the import on UniverseApplication.
Additionally, we've got a clean abstraction that shields us from ``fastapi`` imports in all of our controllers. It should make it more possible to switch to new frameworks and such as the Python ecosystem matures.
Also, the same DI that is used to inject ``RoleManager`` into this contoller is used to inject app into RoleManager when it is constructed during application initialization. Any component being managed by UniverseApplication can now rely on its constructor arguments to be injected if it wants. It is easy to see the cool examples on FastAPI and think it is just a technology for controllers, but it totally is not.
I don't think there is really a way to use FastAPI's dependency injection outside the context of that framework, but even if one could Lagom is superior. All the auto-wiring is by type and requires zero framework and zero configuration (https://github.com/meadsteve/lagom#auto-wiring-with-zero-configuraton).
Having a web framework provide these framework-bound extension points for injecting stuff into controllers was the state of the art of Java like 15 years ago. Skipping that whole learning process and using the type system and auto-wiring that isn't dependent on framework annotation really jumps out to Java circa 8 years ago!
Why Lagom is an interesting question. When researching DI frameworks, I couldn't find a clear winner but Lagom focus on type annotations versus annotating by name makes it clearly more modern than a lot frameworks by much bigger names (https://github.com/meadsteve/lagom/blob/master/docs/comparison.md). The other type-centric framework that had even a nice interface that I found was punq (https://punq.readthedocs.io/en/latest/). The development just doesn't seem as active on punq. While I didn't land up using the integration Lagom seems to have async frameworks in mind (https://github.com/meadsteve/lagom/blob/master/lagom/integrations/fast_api.py), so that is another plus. Ultimately though I think I can swap between these two with like 10 lines of code switch, they do cool things with very simple interfaces and neither requires a bunch of investment in annotation on your components.
This avoids holding on to sessions while a response is being streamed.
Also adds unit tests that verify sessions are really request or thread
local (in case of background threads / non request actions (e.g job /
workflow handlers)).
this is still not ideal, as the entire response will be loaded into
memory. This is a problem with streaming responses.
https://github.com/encode/starlette/issues/1012#issuecomment-673461832
is actually enlightening here:
> "This means this class will either load the entirety of streaming requests into memory (this issue) and run the background before returning the response (#919 ), or if we fix those problems, that it will then encourage users to leave resources in a pending or open state, an arguably worse result. In short, it's problematic."
Which is exactly what we'd be doing with a middleware, keeping resources
open for longer than necessary, which we need to avoid if we ever want
to run background / async tasks. I think the solution here what we
already had, path operation dependencies.
Nate Coraor