Constructor DI?

[dpgraham4401]

Maybe I'm missing something in the docs, I don't see docs on a way to just do simple constructor injection. I guess you could do something like the following?

def __init__(client: MyHttpClient = None)
    Self.client = client or svcs.X.get(MyHttpClient)

But without an approach like this, we can't test a class without setting up the services container and passing all dependencies in that way.

Am I missing something?

[hynek]

I think you want #94?

[dpgraham4401]

Yeah, I would say it's in the same thread as #86.

The docs don't talk about how to use svrc package in conjunction with the __init__ method (what I think of as the equivalent to a Java class constructor). If I needed to instantiate a Java class (e.g., for a unit test), I can still do that and simply pass mock classes to the constructor without having to set up a container.

Not sure if the proposals in #94 just leave that part out for brevity, but unless I'm missing something, the docs give the impression that the svrc package expects you to only instantiate classes through svrc api in production and tests as well.

[hynek]

the docs give the impression that the svrc package expects you to only instantiate classes through svrc api in production and tests as well.

I feel like it’s quite the opposite! It’s one of svcs’s core imperatives to not pollute your code and do injection only from the outside. Therefore, you can instantiate those classes in your tests by just passing them whatever and be done. Independently from DI, doing side-effect-causing actions in __init__ is nowadays frowned upon in Python land (if we need side effects to instantiate a class, we usually go for a classmethod that collects the data and then calls the initializer).

What you’re asking for is magical global state that can be accessed from everywhere and that couples your services to your DI/DL mechanism. I think there’s general consensus that mutable global state and coupling are bad which is why svcs’s design does its best to push it to the edges to keep your code clean and easy to reason about.

You can in fact have what you want with Flask’s integration already because it is based on thread locals (since all of Flask is). And you could totally implement something similar yourself based on the same primitives, but I would encourage you to try our approach first, even if it seems foreign at first.

[dpgraham4401]

Maybe I'm just missing something in the docs, happy to be proven wrong.

Can you provide an example of how I would test a class without using the svrc API to register a dependency? All of the testing examples in the docs use the reigster_value method to inject dependencies. I can't just do something like the following?

def test_foo_bar(my_mock):
    foo = MyClass(my_class_dep=my_mock)
    assert foo.bar() is True

[hynek]

Yes, it's funny when two people coming from different backgrounds try to talk about the same thing, but there're silent assumptions that make it sounds like they speak different languages.

You can write foo = MyClass(my_class_dep=my_mock) of course! Because MyClass doesn't even know svcs exists. And svcs, if told so, will also just do the same! For example (avoiding integration magic for a moment):

registry = Registry()
registry.register_factory(MyClassDep, MyClassDep)
registry.register_factory(MyClass, lambda svcs_container: MyClass(svcs_container.get(MyClassDep)))`

with Container(registry) as con:
   mc = con.get(MyClass)

is equivalent to:

mc = MyClass(MyClassDep())

This is a core tenet of svcs to not couple your classes to the IoC container. It expects you to pass MyClass's dependency as an argument to the constructor – always. That simplifies your classes, because everything they need to do their job is handed to them, ready to use.

---

And as I'm reading from your previous messages, that's what's bothering you. You would like to use svcs inside your classes:

class MyClass:
    def __init__(self, client: MyHttpClient = None)
        self.client = client or svcs.X.get(MyHttpClient)

If you can make the X in this __init__ work, this code will totally work. But that's not what svcs is designed for and that's what's what I think is confusing to you about the testing docs: They ignore the simple case where you just instantiate a class by passing it argument and focus on the case of integration/functional tests, where you don't manually instantiate classes, but some framework does.

Those classes are traditionally difficult to replace, so for example if you take the Flask example in https://svcs.hynek.me/en/stable/integrations/flask.html#testing create_app has already created and configured your application. Now you want to change the way database connections are acquired, for example, to return a mock. This is something that would require ad-hoc patterns like monkey patching or g-shenanigans otherwise and svcs offers you a well-defined interface to achieve that.

But you only need it, if you can't instantiate your classes yourself.