This is a non-exhaustive list of known caveats to the usage of this library.
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
orisinstance
builtin functions. If one must type check using the type's__qualname__
attribute is a possible workaround.
As described in this issue: pytest-dev/pytest#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.