Just some thoughts

[elfjes]

Hey @hynek,

I'm the guy that did a similar thing to svcs (https://github.com/elfjes/gimme-that). At EuroPython you asked for some feedback, so here we go :)

First of all, I like the simplicity of the registry/container design. Registries are for factories, and containers contain instances. Easy.

However, the register_value method seems to break this pattern. Now an instance is present at the registry-level instead of the container level. What if there'd be a Containter.add method that adds an instance (and a Container.remove to remove/forget an instance) (perhaps implement __getitem__, __setitem__ and __delitem__) Seems to me that'd make it more clean. During testing you can then also just create a new container (fixture) for every test and don't need to mess with the registry itself.

I like the ability to close/cleanup instances and the fact that it can do async cleanup. In general, having async support is nice!

Factories currently do not accept parameters. However, they can ask for other services through the 'Quality of Life' module. Would it make sense to you to allow a factory to take an (optional) container argument that can be used to get other services to reduce the
dependency on a global object. This would also be beneficial for dealing with some locality issues, such as when using threadlocal data or ContextVar. You could make it a truly optional argument by inspecting the factory function to check if it requires an argument and only then supply it.

The health check support seems nice, although it seems to me it pollutes both the registry and the container with something that is really specific. However, I currently do not have a better idea on how to implement it. There also seems to be some overlap with the on_registry_close functionality in that it allows for associating a factory with some callback. Maybe there is something there to make it cleaner?

Speaking of health checks. Would it make sense to allow ServicePing.ping to return a value? It would allow for more detailed health checks.

Finally, if you'd be open to it, we could combine our efforts and merge functionality of our two packages into one. I'm currently thinking of the following

• you said you liked the name gimme-that. We can keep that if you want
• I like your approach and simplicity. I do think that I added some unnecessary complexity into my design
• I do like having a package-global registry+container+api. Like a 'Quality of Life' module, but builtin.
• I would also like to have (optional) type hint support for defining dependencies / DI like approach. I'm thinking of an inject-factory function (name pending) that could be used like the following:

registry.register_factory(
    MyService,
    factory=inject(MyService)
)

the inject function would return a callable that looks at the signature/type hints and request those services from the container (requires a supplied Container as an argument)

[hynek]

I'm the guy that did a similar thing to svcs (https://github.com/elfjes/gimme-that). At EuroPython you asked for some feedback, so here we go :)

Thanks for getting back to me with thoughtful feedback no less!

However, the register_value method seems to break this pattern. Now an instance is present at the registry-level instead of the container level. What if there'd be a Containter.add method that adds an instance (and a Container.remove to remove/forget an instance) (perhaps implement __getitem__, __setitem__ and __delitem__) Seems to me that'd make it more clean. During testing you can then also just create a new container (fixture) for every test and don't need to mess with the registry itself.

I'm not sure I follow. For me the main difference between Registries and Containers is their lifecycle. A value has the same lifetime as a Registry; so it makes sense to me to let it live in the Registry?

Factories currently do not accept parameters. However, they can ask for other services through the 'Quality of Life' module. Would it make sense to you to allow a factory to take an (optional) container argument that can be used to get other services to reduce the dependency on a global object. This would also be beneficial for dealing with some locality issues, such as when using threadlocal data or ContextVar. You could make it a truly optional argument by inspecting the factory function to check if it requires an argument and only then supply it.

That makes a lot of sense; I never quite realized that recursive resources only work with Flask's threadlocal approach, because I didn't need it elsewhere until now (full disclosure: I currently only use svcs with Flask and AIOHTTP whose integration I'm close to merging).

The health check support seems nice, although it seems to me it pollutes both the registry and the container with something that is really specific. However, I currently do not have a better idea on how to implement it.

I understand your concern, but I'm not going for purity but to get rid of common boilerplate. :)

I guess there could be a more general approach that employs some kind of metadata and filtering on that, but I think I can live with the current solution for now.

There also seems to be some overlap with the on_registry_close functionality in that it allows for associating a factory with some callback. Maybe there is something there to make it cleaner?

Does it? You mean like a general callback system on certain lifecycle stages? I mean that sounds interesting, but I suspect it's better to watch adoption/feedback to get a better idea of what's used/needed. 🤔

Speaking of health checks. Would it make sense to allow ServicePing.ping to return a value? It would allow for more detailed health checks.

It would! I'm just trying to keep the API envelope as narrow as possible for now to avoid painting myself into a corner.

Finally, if you'd be open to it, we could combine our efforts and merge functionality of our two packages into one.

That's at least currently not possible for me, because I'm iterating too fast (including the occasional git push -f) 😱. svcs as it stands is currently an internal package that I'm trying to make publicly consumable but I can't agree to anything that might slow my iteration down.

I'm currently thinking of the following

• you said you liked the name gimme-that. We can keep that if you want

I do like it, but is it a good name for mass-adoption? 😅 I actually literally don't know; I'm not famous for great package-naming.

• I like your approach and simplicity. I do think that I added some unnecessary complexity into my design
• I do like having a package-global registry+container+api. Like a 'Quality of Life' module, but builtin.

I wonder what it would take to make gimme-that a convienience-wrapper around svcs?

What would you consider a good mechanic for QoL? I was thinking contextvars.

• I would also like to have (optional) type hint support for defining dependencies / DI like approach. I'm thinking of an inject-factory function (name pending) that could be used like the following:

registry.register_factory(
    MyService,
    factory=inject(MyService)
)

the inject function would return a callable that looks at the signature/type hints and request those services from the container (requires a supplied Container as an argument)

Could you elaborate a bit more please?

Assuming MyService(x: int, y: float), you'd expect inject create a factory that does lambda container: MyService(x=container.get(int), y=container.get(float)?

Except for the container argument, would there be anything stopping you from implementing it yourself? 🤔 ← this is generally my litmus test for good APIs: build it in a way such that people can help themselves 99% of the time

---

Thanks again and keep the feedback coming! I'm getting increasingly excited about this project, even if it's gonna have only two users. ;)

[hynek]

JFTR I've decided to make this a discussion so we can keep it running and open actionable issues as they appear.

[elfjes]

I'm not sure I follow. For me the main difference between Registries and Containers is their lifecycle. A value has the same lifetime as a Registry; so it makes sense to me to let it live in the Registry?

I would think that register_value is mainly used for testing purposes. For application code, you'd generally use factory functions. For testing you may for example want to supply a (prepared) mock object. Using register_value, you're now in principle tying the lifetime of your registry to that of your container, since you'd want to get a fresh mock for every test, or you'd need to do some replace_valueing or mock resetting, both of which look more like a workaround/code smell to me. Begin able to just add a Mock (or some stateful Fake implementation) to a container, you can now have a pure registry that may outlive multiple test functions, and have a fresh container for every test.

But in the end it might be just a matter of preference, both work :)

I understand your concern, but I'm not going for purity but to get rid of common boilerplate. :)

I guess there could be a more general approach that employs some kind of metadata and filtering on that, but I think I can live with the current solution for now.

There also seems to be some overlap with the on_registry_close functionality in that it allows for associating a factory with some callback. Maybe there is something there to make it cleaner?

Does it? You mean like a general callback system on certain lifecycle stages? I mean that sounds interesting, but I suspect it's better to watch adoption/feedback to get a better idea of what's used/needed. 🤔

Yeah that makes sense :)

Speaking of health checks. Would it make sense to allow ServicePing.ping to return a value? It would allow for more detailed health checks.

It would! I'm just trying to keep the API envelope as narrow as possible for now to avoid painting myself into a corner.

sounds reasonable

Finally, if you'd be open to it, we could combine our efforts and merge functionality of our two packages into one.

That's at least currently not possible for me, because I'm iterating too fast (including the occasional git push -f) 😱. svcs as it stands is currently an internal package that I'm trying to make publicly consumable but I can't agree to anything that might slow my iteration down.

I'm currently thinking of the following

• you said you liked the name gimme-that. We can keep that if you want

I do like it, but is it a good name for mass-adoption? 😅 I actually literally don't know; I'm not famous for great package-naming.

• I like your approach and simplicity. I do think that I added some unnecessary complexity into my design
• I do like having a package-global registry+container+api. Like a 'Quality of Life' module, but builtin.

I wonder what it would take to make gimme-that a convienience-wrapper around svcs?

That is actually a good idea. I think most of the functionality would be easily reimplemented using svcs as a basis. I would need to rethink containers/repositories as context managers or get rid of it. I can currently do this:

@pytest.fixture
def repository(): # a repository serves both as a registry and a container
    with gimme.context() as repo:
        yield repo

this creates a layer on top of an existing repository (ie the global/QoL repository) on which I can add instances and factories that are cleaned up when the context exits scope, very useful for testing. Requesting an instance using the global api (QoL) always starts at the top of the stack. If a factory or instance doesn't exist on the current layer, it moves down the stack until it finds one. I can then use it like this

@pytest.fixture(autouse=True)
def mocked_service(repository):
    class FakeService(MyService):
        """some fake implementation"""
    repository.add(FakeService())

any test that that uses code that requests a MyService gets a clean FakeService instance. I can create different layers for different lifecycles (session, class, function...)

I'd need to think about the necessity of this functionality and/or how to implement it using svcs.

What would you consider a good mechanic for QoL? I was thinking contextvars.

contextvar would solve locality issues, but if it is the default approach it might also result in non-obvious behaviour, if a user does some instantiating in a separate Task and expects the result to be carried over to other tasks. I currently do not have a specific use case requiring concurrent contexts, so my approach would be to start with a naive module-global and solve problems as they arise

Could you elaborate a bit more please?

Assuming MyService(x: int, y: float), you'd expect inject create a factory that does lambda container: MyService(x=container.get(int), y=container.get(float)?

yes that would be exactly it. I would add it to a next version of gimme-that :)

So for now I think basing gimme-that on svcs is the way forward for me :). *mumbles something about version pinning

[hynek]

I'm not sure I follow. For me the main difference between Registries and Containers is their lifecycle. A value has the same lifetime as a Registry; so it makes sense to me to let it live in the Registry?

I would think that register_value is mainly used for testing purposes. For application code, you'd generally use factory functions. For testing you may for example want to supply a (prepared) mock object. Using register_value, you're now in principle tying the lifetime of your registry to that of your container, since you'd want to get a fresh mock for every test, or you'd need to do some replace_valueing or mock resetting, both of which look more like a workaround/code smell to me. Begin able to just add a Mock (or some stateful Fake implementation) to a container, you can now have a pure registry that may outlive multiple test functions, and have a fresh container for
every test.

You'd think so! But I've found that in my existing projects it sometimes makes sense to just have a singular object available. You don't always want a live pool for example (for instance HTTP clients that run ~1x per day).

[elfjes]

So if I understand you correctly, you have a use case where, inside a running application, you go through multiple containers / container lifecycles, or have multiple containers in parallel, where you need a service that is either expensive to instantiate or needs to preserve some state throughout the lifetime of the application so that you only want to instantiate it once, ever, no matter your container life time. I'm probably not understanding you correctly but that sounds to me like a really niche use case. I'm not trying to be pedantic, I'm just curious :)

You mention a http client that runs once a day. Why not just create a new client if your old container has expired and you need a new one? What's the purpose of keeping it? Surely the overhead of recreating it is limited, especially for something that only runs once a day? Having such a long lived object also might mean that you'd need to validate some internal state: I can for example imagine a http client having a dns cache that may be invalid after 24 hours?

[hynek]

Eh yeah maybe I misspoke a bit, but sometimes you (or: I) want to get back an on-demand pool for various reasons. I mean testing is one of them. So I think it's nice to have; at least I use it a lot even thought it might be due to the fact I'm porting old-style apps so they're not entirely optimized for svcs. But giving people tools for a nicer migration is worth it either way.

[hynek]

Ah I've remembered one thing.

Sometimes, I want something to be pluggable, but it doesn't have to be a resource like a database or something.

For instance I've got a JWT verifier where it just doesn't make any sense to use it as a factory. But it's nice to easily replace it at runtime.

[hynek]

@elfjes jftr svcs 23.7 is on PyPI now that allows passing a container. I've just needed it myself in a Pyramid app! :)

[hynek]

@elfjes I'm at a point where I think svcs is ready to be pronounced stable. Do you have anything that would speak against it? There's been a lot of changes since we last spoke. 😅

[elfjes]

Yeah I see, you've been busy :D

On overall, things look nice, I'm especially impressed by the thorough docs.

There is one thing that, the more I look at it, starts to look a bit off, and that has to do with the lifetime of a Container. There are (roughly) two statements in the docs about it

• A container lives as long as you want the instances to live – for example, as long as a request lives.
• The svcs.Container object should live on a request-scoped object like Flask’s g object.

While not directly contradicting eachother, the second statement is much stronger than the first (COULD vs SHOULD). I'd say that COULD would be preferable over SHOULD. If svcs starts expecting a specific lifetime for a container, that would be undesirable imho.

This approach also leaks in how the lifetime of longlived services is handled. Within an application there are long lived services, such as a connection pool, and short lived services, such as a single connection. Short lived services are to be registered using Registry.register_factory and for long lived services it is required to run the factory yourself at application startup and use Registry.register_value. If I want to have cleanup logic, I have to use an on_registry_close callback and cannot use the nicer generator/context_manager approach (directly). The api changes (arbitrarly) based on a required lifetime of a service which is strange to me. Also, this means that there are ever only two lifetimes available: long and short, which sounds arbitrary. What if I'd want a third, medium, lifetime? It seems to me that what you'd really want is to somehow specifiy a lifetime in a more flexible way, or be able to create multiple containers that work together and manage the lifetime of those containers explicitly/separately.

Now for testing, some more strange things start to pop up. For the flask plugin, you've introduced overwrite_(factory|value) methods to deal with some quirks that (I think) follow from this usage pattern. After making changes to the registry, they close/flush the container. That seems quite a strong action. It means that it needs to be used carefully since service finalizers (on_close) will be called, so any service that has already been requested from the container may be rendered unusable. Also it only calls synchronous finalizers, although I guess when using the flask integration, it is unlikely that there are any async finalizers, but still. Maybe for testing this is all fine, but I would not recommend using the functionality outside of testing, perhaps it deserves a warning in the docs?

Now, I'm not trying to be overly negative here. I still really like what you've created (!), but the above is a concern to me. It seems to me that it is a design choice that may hamper future developments, especially once this api becomes stable.

[hynek]

On overall, things look nice, I'm especially impressed by the thorough docs.

I don't think I'm exaggering when I say that I've spent more time on the docs than on code at this point. 😅

There is one thing that, the more I look at it, starts to look a bit off, and that has to do with the lifetime of a Container. There are (roughly) two statements in the docs about it

• A container lives as long as you want the instances to live – for example, as long as a request lives.
• The svcs.Container object should live on a request-scoped object like Flask’s g object.

While not directly contradicting eachother, the second statement is much stronger than the first (COULD vs SHOULD). I'd say that COULD would be preferable over SHOULD. If svcs starts expecting a specific lifetime for a container, that would be undesirable imho.

Well, svcs doesn't care at all – but people prefer clear instructions? I guess I can rephrase it more like a suggestion.

This approach also leaks in how the lifetime of longlived services is handled. Within an application there are long lived services, such as a connection pool, and short lived services, such as a single connection. Short lived services are to be registered using Registry.register_factory and for long lived services it is required to run the factory yourself at application startup and use Registry.register_value. If I want to have cleanup logic, I have to use an on_registry_close callback and cannot use the nicer generator/context_manager approach (directly). The api changes (arbitrarly) based on a required lifetime of a service which is strange to me.

Hm I feel like you're off here and I wonder what to do to the docs to prevent this. Both long- and short-lived services have a perfect symmetry, because in both cases you can use on_registry_close to clean up the item that is bound to the registry – and I do it all the time (e.g., engine.connect as factory, lambda: engine.dispose for on_registry_cleanup).

Also, this means that there are ever only two lifetimes available: long and short, which sounds arbitrary. What if I'd want a third, medium, lifetime? It seems to me that what you'd really want is to somehow specifiy a lifetime in a more flexible way, or be able to create multiple containers that work together and manage the lifetime of those containers explicitly/separately.

I mean you're free to keep a container longer around – they are all entirely self-sufficient as long as the registry is alive. Is anything stopping you? Containers are even context managers themselves now.

Now for testing, some more strange things start to pop up. For the flask plugin, you've introduced overwrite_(factory|value) methods to deal with some quirks that (I think) follow from this usage pattern. After making changes to the registry, they close/flush the container. That seems quite a strong action. It means that it needs to be used carefully since service finalizers (on_close) will be called, so any service that has already been requested from the container may be rendered unusable.

Yeah, but there's no way around that with recursive services. We could try to keep some kind of DAG to flush only dependencies of what you're flushing, but that seems a) overkill for testing and b) much harder to reason about.

Also it only calls synchronous finalizers, although I guess when using the flask integration, it is unlikely that there are any async finalizers, but still.

The Flask integration offers only sync helpers in general. I mean technically Flask has async support too, but I don't think we need that for going stable.

Maybe for testing this is all fine, but I would not recommend using the functionality outside of testing, perhaps it deserves a warning in the docs?

I hope this works: 2597265

Now, I'm not trying to be overly negative here. I still really like what you've created (!), but the above is a concern to me. It seems to me that it is a design choice that may hamper future developments, especially once this api becomes stable.

Thanks again for your throughtful feedback! I'm glad to see it's mostly about improving docs at this point.

[elfjes]

Well, svcs doesn't care at all – but people prefer clear instructions? I guess I can rephrase it more like a suggestion.

That's good :)

Hm I feel like you're off here and I wonder what to do to the docs to prevent this. Both long- and short-lived services have a perfect symmetry, because in both cases you can use on_registry_close to clean up the item that is bound to the registry – and I do it all the time (e.g., engine.connect as factory, lambda: engine.dispose for on_registry_cleanup).

Right. That still feels a bit asymmetric to me. It links the factory for a Connection, to a cleanup of an Engine. It would feel more "correct" to me to be able to write something like this:

def engine_factory():
    engine = create_engine("postgresql://localhost")
    yield engine
    engine.dispose()

def connection_factory(svcs_container):
    return svcs_container.get(Engine).connect() # hurray for automatic exiting of contextmanagers 


svcs.flask.register_factory(app, Engine, engine_factory)
svsc.flask.register_factory(app, Connection, connection_factory)

which doesn't currently work properly because the engine would be destroyed for every request (assuming a short lived container). Then, to me, the next best thing would be:

engine = create_engine("postgresql://localhost")
svcs.flask.register_value(app, Engine, engine, on_registry_close=engine.dispose)

but that feels clunky.

So right now, the simplest would be the pattern you suggest here and in the docs: create a higher scoped engine object and use that as a closure directly in your factories/cleanup functions. For a Sqlalchemy Engine I guess that is fine. but what if I have an Engine (or similar object) with a more complex factory? or what if it has other services it depends on? Do I have to create them all as higher scoped objects?

class Service:
    ...

@attrs.define
class MyEngine:
    dep: Service
    ...

def create_engine_very_complex(base: Service):
    engine = MyEngine(base)
    # some more logic
    ...
    return engine

def app():
   """not necessarily a flask app"""
   registry = svcs.Registry()
   base = Service()
   engine = create_engine_very_complex(base)
   registry.register_value(Service, base, on_registry_close=base.close)
   registry.register_value(MyEngine, engine, on_registry_close=engine.close)
   ...

Now I've statically tied my engine to that MyBaseService instance. What if Service is an abstract class/interface, and at startup I want to determine which implementation to use?

class ServiceA(Service):
   ...

class ServiceB(Service):
   ...

def create_service():
   return ServiceA() if os.environ['SERVICE_KIND'] == 'a' else ServiceB()

One of the beauties of a framework like svcs to me is that it provides a separation between defining your factories and instantiation of the objects. You supply a factory, and at some point that factory may be called. In its current implementation, this only works for objects whose lifetime matches the lifetime of a container. For a higher duration lifetime, you're bound to creating them yourself and feeding them to other factories, either through register_value or by supplying them as closures. Now i have to write something like this myself:

service = create_service()
engine = create_engine_very_complex(service)
...

which I was trying to avoid by using svcs

I mean you're free to keep a container longer around – they are all entirely self-sufficient as long as the registry is alive. Is anything stopping you? Containers are even context managers themselves now.

Yes I can create multiple containers, but I would not be able to request a recursive dependency from another container. The containers are completely independent from each other.

I hope this works: 2597265

Yeah that works against accidental production usage of overwrite :)

[hynek]

Then, to me, the next best thing would be:

engine = create_engine("postgresql://localhost")
svcs.flask.register_value(app, Engine, engine, on_registry_close=engine.dispose)

but that feels clunky.

FWIW that’s what I’m doing naturally which led to the APIs.

So right now, the simplest would be the pattern you suggest here and in the docs: create a higher scoped engine object and use that as a closure directly in your factories/cleanup functions. For a Sqlalchemy Engine I guess that is fine. but what if I have an Engine (or similar object) with a more complex factory? or what if it has other services it depends on? Do I have to create them all as higher scoped objects?

class Service:
    ...

@attrs.define
class MyEngine:
    dep: Service
    ...

def create_engine_very_complex(base: Service):
    engine = MyEngine(base)
    # some more logic
    ...
    return engine

def app():
   """not necessarily a flask app"""
   registry = svcs.Registry()
   base = Service()
   engine = create_engine_very_complex(base)
   registry.register_value(Service, base, on_registry_close=base.close)
   registry.register_value(MyEngine, engine, on_registry_close=engine.close)
   ...

Now I've statically tied my engine to that MyBaseService instance. What if Service is an abstract class/interface, and at startup I want to determine which implementation to use?

class ServiceA(Service):
   ...

class ServiceB(Service):
   ...

def create_service():
   return ServiceA() if os.environ['SERVICE_KIND'] == 'a' else ServiceB()

One of the beauties of a framework like svcs to me is that it provides a separation between defining your factories and instantiation of the objects. You supply a factory, and at some point that factory may be called. In its current implementation, this only works for objects whose lifetime matches the lifetime of a container. For a higher duration lifetime, you're bound to creating them yourself and feeding them to other factories, either through register_value or by supplying them as closures. Now i have to write something like this myself:

service = create_service()
engine = create_engine_very_complex(service)
...

which I was trying to avoid by using svcs

OK, so would it be enough for you if register_value did the same thing as the factories and looked at the value and if it’s generator/context manager it’s used to produce the value and register it for cleanup?

I mean you're free to keep a container longer around – they are all entirely self-sufficient as long as the registry is alive. Is anything stopping you? Containers are even context managers themselves now.

Yes I can create multiple containers, but I would not be able to request a recursive dependency from another container. The containers are completely independent from each other.

I feel/hope like adding containers that depend on other containers should be possible to add later?

[hynek]

OK, so would it be enough for you if register_value did the same thing as the factories and looked at the value and if it’s generator/context manager it’s used to produce the value and register it for cleanup?

Hm no this can't work with async. It might also be a bit confusing.

Maybe I'll add something like register_factory(..., singleton=True) where the service is created on first aget/get() and then cached within the registry with cleanup via close(registry).

But that doesn't seem like something that has to ship in the first stable version, no?

[elfjes]

My apologies for not replying earlier, I've been a bit busy. I was thinking about a nice way to do that. A singleton flag might achieve that, basically saying "don't store the instance on the container, but store it in the registry instead". Maybe the result will be that there is another container attached to the registry which contains all the singleton instances? Sounds interesting, for gimme-that i'm currently playing with combining the registry and a container into a ServiceLocator class to allow for some more interaction between containers and the registry. I should really get on with commiting a minimal working version...

As for whether it is required for a first stable version, that's up to you I guess. For me that lifecycle-flexibililty is quite crucial, but I think I can achieve that using svcs current functionality/api. So then it depends on whether you feel you've captured and fixed the core of the api sufficiently to not break it for the coming - however long - period.

[hynek]

I thought about it some more and I think I would even give it a Registry.register_singleton_factory() method whose name makes it more clear what it does than a random bool argument. Using an internal container for that kind of services (and on_registry_close) is a good idea and might help getting rid of some code duplication!

[hynek]

As for whether it is required for a first stable version, that's up to you I guess. For me that lifecycle-flexibililty is quite crucial, but I think I can achieve that using svcs current functionality/api. So then it depends on whether you feel you've captured and fixed the core of the api sufficiently to not break it for the coming - however long - period.

Yeah to be clear: I've spent so much time on the project in the past months, neglecting all my other projects, and I'm kinda running out of steam. If the current state doesn't paint me into a corner and pronouncing the current public APIs stable doesn't make our singleton dreams impossible, I think I'm gonna punt on it for now.

[guacs]

I would also like to have (optional) type hint support for defining dependencies / DI like approach. I'm thinking of an inject-factory function (name pending) that could be used like the following:
registry.register_factory(
MyService,
factory=inject(MyService)
)
the inject function would return a callable that looks at the signature/type hints and request those services from the container (requires a supplied Container as an argument)

Could you elaborate a bit more please?

Assuming MyService(x: int, y: float), you'd expect inject create a factory that does lambda container: MyService(x=container.get(int), y=container.get(float)?

Except for the container argument, would there be anything stopping you from implementing it yourself?

While it's true the user could do that themselves, I think it'd be a nice feature to have built in. Though I think a nicer API than the inject suggested by @elfjes would be to have a resolve_dependencies flag in the register_factory method. I feel like this form of dependency injection into the factory functions would be expected by users (or at the very least, I expected it).