+ +
+

Caveats

+

This is a non-exhaustive list of known caveats to the usage of this library.

+
+

Automatic dependency discovery

+

Injectable automatic dependency discovery system is inspired from Airflow’s DAG automatic +discovery. So first all files in the search path are recursively read looking for any +occurrence of the following four strings: @injectable, injectable(, +@injectable_factory, and injectable_factory(. Then those files are executed as +python modules so the decorators can register the injectable to the container.

+

This implementation leads to some issues:

+
    +
  • If, for any reason, the code aliases the decorators to other incompatible names or +do not use the decorator functions directly automatic dependency will fail and those +injectables will never be registered to the container.

  • +
  • Any file containing these strings will be executed causing potential unintended +side-effects such as file-level code outside classes and functions being executed.

  • +
  • The module of each injectable class may be loaded twice: one for in this automatic +discovery step and another by the regular application operation. This will render +impossible to run type checks for injected objects through the use of type or +isinstance builtin functions. If one must type check using the type’s +__qualname__ attribute is a possible workaround.

  • +
+
+
+

Pytest and relative imports

+

As described in this issue: https://github.com/pytest-dev/pytest/issues/9007 , pytest +won’t work with injectable’s automatic dependency discovery system if one declares +injectables in the same file of the test itself, load the injection container during the +test and use relative imports in this file. This corner-case combination will lead to an +AttributeError: 'AssertionRewritingHook' object has no attribute 'get_code'.

+

Currently the workaround for this is either to use absolute imports in these files or to +move the declaration of injectables to any other file other than the test’s file.

+
+
+ + +
+