Implementation of dependency injection for Python 3

Features:

types resolution by signature types annotations (type hints)
types resolution by class annotations (type hints)
types resolution by names and aliases (convention over configuration)
unintrusive: builds objects graph without the need to change the source code of classes
minimum overhead to obtain services, once the objects graph is built
support for singletons, transient, and scoped services

This library is freely inspired by .NET Standard Microsoft.Extensions.DependencyInjection implementation (ref. MSDN, Dependency injection in ASP.NET Core, Using dependency injection in a .Net Core console application). The ContainerProtocol for v2 is inspired by punq.

Installation

pip install rodi

Efficient

rodi works by inspecting code once at runtime, to generate functions that return instances of desired types - as long as the object graph is not altered. Inspections are done either on constructors (__init__) or class annotations. Validation steps, for example to detect circular dependencies or missing services, are done when building these functions, so additional validation is not needed when activating services.

Flexible

rodi offers two code APIs:

one is kept as generic as possible, using a ContainerProtocol for scenarios in which it is desirable being able to replace rodi with alternative implementations of dependency injection for Python. The protocol only expects a class being able to register and resolve types, and to tell if a type is configured in it (__contains__). Even if other implementations of DI don´t implement these three methods, it should be easy to use composition to wrap other libraries with a compatible class.
one is a more concrete implementation, for scenarios where it's not desirable to consider alternative implementations of dependency injection.

For this reason, the examples report two ways to achieve certain things.

Examples

For examples, refer to the examples folder.

Recommended practices

All services should be configured once, when an application starts, and the object graph should not be altered during normal program execution. Example: if you build a web application, configure the object graph when bootstrapping the application, avoid altering the Container configuration while handling web requests.

Aim at keeping the Container and service graphs abstracted from the front-end layer of your application, and avoid mixing runtime values with container configuration. Example: if you build a web application, avoid if possible relying on the HTTP Request object being a service registered in your container.

Service life style:

singleton - instantiated only once per service provider
transient - services are instantiated every time they are required
scoped - instantiated only once per root service resolution call (e.g. once per web request)