One of the use case is to Inject an instance of HttpBearer in FastAPI routes

since the instance will have a different type than the class definition itself, this doesn't inject the instance as a dependency. Is there a workaround? Thanks

Resolves #129

These changes allow calling Container.partial and Container.magic_partial with a class Callable. It also supports using the bind_to_container and magic_bind_to_container decorators on classes.

Tests added for relevant methods in:

• test_partial_classes.py
• tests_magic_partial_classes.py

Let me know if anything looks strange or if you feel the test coverage is not adequate.

Since the container implements a dictionary interface it should be possible to analyse the code and generate a dictionary that can be dropped in place of the container. This would avoid any reflection happening at runtime.

One more issue to throw your way @meadsteve 😅

It seems @dependency_definition doesn't work for generator functions with the c: Container parameter, e.g.:

@dependency_definition(container)
def _session_dependency(container: Container) -> Generator[Session, None, None]:
    read_only: bool = container[Request].scope["db_access"] == "READ_ONLY"
    with get_db_session(read_only) as session:
        yield session

This gives the following error:

ImportError while loading conftest '/home/rbarrie/code/gdb/tests/unit/api/conftest.py'.
tests/unit/api/conftest.py:10: in <module>
    from gdb.entrypoints.bootstrap import deps
gdb/entrypoints/bootstrap.py:133: in <module>
    def _session_dependency(container: Container) -> Session:
../../.cache/pypoetry/virtualenvs/gdb-wpT7sdDb-py3.8/lib/python3.8/site-packages/lagom/decorators.py:69: in _decorator
    definition_func, return_type = _extract_definition_func_and_type(func)  # type: ignore
../../.cache/pypoetry/virtualenvs/gdb-wpT7sdDb-py3.8/lib/python3.8/site-packages/lagom/decorators.py:102: in _extract_definition_func_and_type
    return value_from_gen, return_type.__args__[0]  # todo: something less hacky
E   AttributeError: type object 'Session' has no attribute '__args__'

For comparison a simple generator function without the c: Container parameter works fine:

@dependency_definition(container)
def _session_dependency() -> Generator[Session, None, None]:
    with get_db_session(False) as session:
        yield session

I'm not sure if this is by design or not?

I may be being too ambitious here but I want to have each of my FastAPI endpoints determine (via a custom APIRoute + Request.scope attribute) which DB transaction / connection is used (read/write vs read-only). I suppose I could achieve this with two independent Lagom containers, but then I would have two of every dependency initialised...

Hi Steve,

Love the framework so far. One issue I'm having is in trying to use FastAPI dependency overrides in a similar manner to vanilla FastAPI, when making web-layer unit tests. I.e. mocking out dependencies.

In vanilla FastAPI you would do something like this (with pytest):

...
from fastapi.testclient import TestClient
from dependencies import get_foo_service  # <-- Dependency function
from foo import FooService
...

@pytest.fixture
def foo_service_mock():
    return Mock(FooService)

@pytest.fixture
def client(foo_service_mock) -> Generator:
    app.dependency_overrides[get_foo_service] = lambda: foo_service_mock

    with TestClient(app) as c:
        yield c

But I can't see how I could replicate the override (app.dependency_overrides[get_foo_service]) functionality when using the Lagom FastAPI DI approach (i.e. when using deps.depends(FooService)).

I suppose I would somehow need to reference the inner _resolver function of depends...surely this isn't possible?

Thus it would be nice if there were explicit support for FastAPI dependency overrides.

Thanks!

Closes #166

Hey Steve! I was playing around with lagom and starlette and noticed there was a recent issue about this.

This PR handles starlette's class-based views hopefully in a reasonably idiomatic way. The basic approach is to wrap the endpoint in a proxy class which ignores existing attributes from HTTPEndpoint but otherwise use lagom's DI to wrap what's assumed to be a handler function.

Now that I look at it in a diff, potentially a more robust approach would be to wrap only attributes named after HTTP methods and otherwise not interfere, since (in theory, not sure why you would since you have no control over the way __init__ gets called) there could be custom non-route properties on a subclass of HTTPEndpoint.

Happy to discuss / make changes either way!

Hi!

Strangely I'm unable to make DI work with async / await coroutines as instance methods. Codes:

import asyncio
from lagom import Container, injectable
class Foo: pass
class Bar: pass
class CoroutineHolder:
    async def coroutine(self, foo: Foo = injectable, bar: Bar = injectable):
        print(foo)
        print(bar)
container = Container()
holder = CoroutineHolder()
coroutine_with_deps = container.partial(holder.coroutine)
asyncio.run(coroutine_with_deps())
# prints the following:
# <lagom.markers.Injectable object at 0x0000026A36369FD0>
# <lagom.markers.Injectable object at 0x0000026A36369FD0>

I inspected into the code a little (I'm not a great python programmer) and it seems Container._get_spec_without_self(self, func: Callable[..., X]) errs when the func argument is a Coroutine:

if isinstance(func, FunctionType):
    spec = self._reflector.get_function_spec(func)
else:
    t = cast(Type[X], func)
    spec = self._reflector.get_function_spec(t.__init__).without_argument(
        "self"
    )
return spec

Coroutines are CoroutineType unrelated to FunctionType, so this function makes a call to __init__, perhaps that is why, or I'm doing something wrong 😄

It appears that the change to how the Alias.skip_definitions flag is used in #150 introduced a regression. If an alias maps a type to itself, any resolution to the alias will raise a RecursionError.

Python 3.9.4 (tags/v3.9.4:1f2e308, Apr  6 2021, 13:40:21) [MSC v.1928 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import abc
>>> import sys
>>> import lagom
>>> sys.tracebacklimit = 5
>>>
>>> class AbstractFoo(abc.ABC):
...   pass
...
>>> class Foo(AbstractFoo):
...   pass
...
>>> container = lagom.Container()
>>>
>>> container[AbstractFoo] = Foo
>>> container[AbstractFoo]
<__main__.Foo object at 0x000001BF1CA4D700>
>>> container[Foo]
<__main__.Foo object at 0x000001BF1CA4D790>
>>>
>>> container[Foo] = Foo
>>> container[AbstractFoo]
Traceback (most recent call last):
  File "X:\lagom\.venv\lib\site-packages\lagom\definitions.py", line 68, in get_instance
    return container.resolve(
  File "X:\lagom\.venv\lib\site-packages\lagom\container.py", line 237, in resolve
    return definition.get_instance(self)
  File "X:\lagom\.venv\lib\site-packages\lagom\definitions.py", line 68, in get_instance
    return container.resolve(
  File "X:\lagom\.venv\lib\site-packages\lagom\container.py", line 235, in resolve
    definition = self.get_definition(dep_type)
  File "X:\lagom\.venv\lib\site-packages\lagom\container.py", line 352, in get_definition
    definition = self._registered_types.get(dep_type, Unset)
RecursionError: maximum recursion depth exceeded while calling a Python object
>>> container[Foo]
Traceback (most recent call last):
  File "X:\lagom\.venv\lib\site-packages\lagom\definitions.py", line 68, in get_instance
    return container.resolve(
  File "X:\lagom\.venv\lib\site-packages\lagom\container.py", line 237, in resolve
    return definition.get_instance(self)
  File "X:\lagom\.venv\lib\site-packages\lagom\definitions.py", line 68, in get_instance
    return container.resolve(
  File "X:\lagom\.venv\lib\site-packages\lagom\container.py", line 235, in resolve
    definition = self.get_definition(dep_type)
  File "X:\lagom\.venv\lib\site-packages\lagom\container.py", line 352, in get_definition
    definition = self._registered_types.get(dep_type, Unset)
RecursionError: maximum recursion depth exceeded while calling a Python object
>>>

This is Python 3.9.4 and Lagom 1.3.0.

Ultimately, this isn't a huge issue. But it seems that a guard condition is merited so the identity map can be allowed.

Not sure if intentional, but I had a need for using Container.magic_partial on a class type as opposed to a function. This throws an error because it's not able to resolve any of the dependencies.

Taking a look at the pathway for Container.resolve, I noticed that it reflects on __init__ whereas magic_partial reflects directly on the callable:

https://github.com/meadsteve/lagom/blob/70127078149c2d209fef8ec229937acb9fa3f03f/lagom/container.py#L384

vs

https://github.com/meadsteve/lagom/blob/70127078149c2d209fef8ec229937acb9fa3f03f/lagom/container.py#L319

I was able to patch this by checking if func is a function or not:

if isinstance(func, types.FunctionType):
    spec = self._reflector.get_function_spec(func)
else:
    spec = self._reflector.get_function_spec(func.__init__)

Which works successfully with something like:

class Foo:
    def greet(self) -> str:
        return "Hello Foo"

class Bar:
    def __init__(self, not_injected: str, foo: foo) -> None:
        self.not_injected = not_injected
        self.foo = foo

    def greet(self) -> str:
        return self.foo.greet() + self.not_injected

container = Container()
container[Foo] = Foo()
bar = c.magic_partial(Bar)(not_injected="!")
bar.greet()

I can open a pull request with the fix above, just wanted to check if this was a design decision first.

Also, thanks for your work on the library!

Similar to: https://fastapi.tiangolo.com/tutorial/dependencies/dependencies-with-yield/

See conversation on this issue: https://github.com/meadsteve/lagom/issues/179#issuecomment-979763975

Stretch goal: make this generic enough to use for all lagom usages.

Magic (the current implementation):

from .dependency_config import container


@container.bind_view
def index(request, dep: SomeService):
    return HttpResponse(f"service says: {dep.get_message()}")

# Or if you prefer class based views

@container.bind_view
class CBVexample(View):
    def get(self, request, dep: SomeService):
        return HttpResponse(f"service says: {dep.get_message()}")

vs. explicit:

from lagom import injectable
from .dependency_config import container


@container.bind_view
def index(request, dep: SomeService=injectable):
    return HttpResponse(f"service says: {dep.get_message()}")

# Or if you prefer class based views

@container.bind_view
class CBVexample(View):
    def get(self, request, dep: SomeService=injectable):
        return HttpResponse(f"service says: {dep.get_message()}")

When resolving request level singletons, Request class from starlette can not be resolved

As an example, editing the tests located at tests/integrations/fastapi_app/__init__.py as;

 from contextlib import contextmanager
 from typing import Iterator
 
-from fastapi import FastAPI
+from fastapi import FastAPI, Request
 
 from lagom import Container, dependency_definition
 from lagom.integrations.fast_api import FastApiIntegration
 
 
 class Inner:
-    def __init__(self, msg=None):
+    def __init__(self, request: Request, msg=None):
         self.msg = msg
+        self.request = request
 

The resolution gives the following error;

lagom.exceptions.UnresolvableType: Unable to construct dependency of type Inner The constructor probably has some unre
solvable dependencies

I will try to make a PR when i have time. But not promise :D

There are broadly three lifetimes:

• Singleton - exists for the life of the container once created.
• Invocation level shared - constructed once during a single function call (wrapped by a lagom decorator).
• Regular - Constructed new every time they are needed.

Special case for a lot of the framework integrations:

• Request level - This is equivalent to the invocation level shared resources above but specifically for the lifetime of a request.

The TLDR goal of this work is to be able to build @strawberry data loaders like this:

class AuthorLoader(DataLoader[str, Author]):
    def __init__(self, some_dep_db: DB):
        super().__init__(self.get_authors)
        self.db = some_dep_db

    async def get_authors(self, ids) -> typing.List["Author"]:
        print(f"Bulk loading authors: {ids}")
        return await self.db.get_the_authors(ids)

and then use it like

container = StrawberryContainer()
container[AuthorLoader] = AuthorLoader

@strawberry.type
class Book:
    title: str
    author_id: int

    @strawberry.field
    @container.attach_field
    async def author(self, loader: "AuthorLoader") -> "Author":
        return await loader.load(self.author_id)

class MyGraphQL(GraphQL):
    async def get_context(self, *args, **kwargs) -> Any:
        context: Dict = {}
        container.hook_into_context(context)
        return context

Lagom allows (and should encourage) containers to be stacked on top of each other. This is especially useful when you have different contexts like a web app and a worker on some job queue that share some dependency construction logic but not all.