Current Maintenance Status and Future Plans

[moccajoghurt]

Hello,

I'm considering integrating this library into my project but noticed the last update was two years ago. Could you confirm if the repository is still maintained and if it's safe to use in terms of security and compatibility?

Thank you for your work on this project and for any information you can provide.

[jasonprado]

I am using it in production for a medium-sized project and it's been a mostly positive experience, but the lack of maintenance has unfortunately made me switch to injector for another new project. Small problems are accruing, like only supporting pydantic v1 and no support for Python 3.12. There are PRs for addressing these issues, so I feel like a fork would be successful.

[jonathangreen]

There are a couple other issues open with a similar question: #688, #742, #763.

In #742 (comment) @rmk135 did respond on Nov 15, 2023, but no response since then. That does make me concerned for the future of this project.

[benm5678]

New to python, it's a bit odd to me such a popular language has no good DI framework... this one is the closest, but some issues popping up and no one to support it. It can always be forked I suppose if there were enough that wanted & are able to support it. Makes me wonder about python usage in large projects...or perhaps there are alternate approaches that explain the lack of options here.

[alexted]

this project is dead. forget about it, make forks, look for alternatives or write on your own.
the author did irresponsible by not handing over the project to anyone. well, god judge him.

[moccajoghurt]

As someone with a .NET background, I've often leaned towards sophisticated frameworks for core functionalities. However, Python's flexibility might not necessitate such complex solutions. In "Architecture Patterns with Python," the authors advocate for a minimalist approach to DI, which they implement succinctly in about 30 lines of code. This perspective is illustrated in their public GitHub repository, which you can view here.

Considering this minimalist approach, I experimented with implementing DI in a similar way in one of my private projects. Here’s a practical example:

def bootstrap(
    httpx: request.AbstractRequests = request.Requests(),
) -> messagebus.MessageBus:
    dependencies = {"http_request": httpx}
    injected_command_handlers = {
        commands.RetrieveXenforoHtml: inject_dependencies(
            xenforo.retrieve_xenforo, dependencies
        ),
    }
    bus = messagebus.MessageBus()
    for command_type, handler in injected_command_handlers.items():
        bus.register_command_handler(command_type, handler)
    return bus

def inject_dependencies(handler, dependencies):
    params = inspect.signature(handler).parameters
    deps = {name: dependency for name, dependency in dependencies.items() if name in params}
    return lambda command: handler(command, **deps)

In this example, bootstrap function sets up a message bus with dependency-injected command handlers, demonstrating DI without the need for a complex framework. This approach might be sufficient for many projects, especially when considering Python's dynamic nature.

I'm curious to hear others' thoughts on this. Have you found that Python projects typically require complex DI solutions, or have simpler approaches like this been adequate?

[alexted]

@moccajoghurt you know, your apt comment made me think that, indeed, modern Python can do without a specialized framework for dependency injection!
Thanks for your valuable opinion - it's useful to have an open mind sometimes!

[benm5678]

@moccajoghurt you know, your apt comment made me think that, indeed, modern Python can do without a specialized framework for dependency injection! Thanks for your valuable opinion - it's useful to have an open mind sometimes!

Not sure I follow... isn't it still desirable to have a nice DI framework, so you can define all injections in a central containers, with easy/clean/flexible options to override, control factory type, and inject in various places throughout the codebase?

[alexted]

These frameworks appear and die like flies. it might be convenient to have a single container, but in general, it doesn't affect anything dramatically, but it creates hemorrhoids - like now, for example, when we have to remove this dead lib from everywhere.

[RubenRibGarcia]

It is a bit sad to let this library to be left like this 😕. I know that a fork was already done, at least to give support to Python 3.12. That said are't we able, as a community, to fork this project and start from there ?

Probably we would "only" need to find a quorum for this to work.

[dcendents]

I've successfully switched to https://github.com/kodemore/kink, it has all the functionalities I need and the implementation is much simpler, so it if gets abandoned I could just maintain the code myself in the project...

[Guibod]

I’ve switched to injector.

[ngirard]

Hey @Guibod ,
how is the switch going so far ? Would you mind elaborating a bit ?
Thanks !

[Guibod]

@ngirard
Well, as you noticed, pdi is pretty complex and use advanced pattern, such as the ressource instance type, with its delayed cleanup through generators. Sometimes it’s pretty magic or even cryptic.

On the other side, injector is a dumb and very basic injector. The team in charge of the project seems pretty reluctant to add advanced features.

A good example is their proposal for our ResourceProvider. The ressource cleanup pattern is detailed in an extra documentation that is awaiting to be merged (see the PR). So that’s doable, but with extra legwork.

In short:

• If you have basic needs, go for injector.
• If you need something well polished, or with advanced patterns support, don’t go (yet), that’s a work in progress
• If you are ready to implement some extra layers, you can mostly achieve anything.
• Kink and Injector are pretty similar as far as I can tell. I’ve follow the crowd on the most popular one.

In detail:

• Injector is simple, and use annotation, that’s great
• Injector does not provide static injector, so each top level instance must define its own injector
• Injector relies on types to identify dependencies, so you need to annotate or NewType your instance of string. I found that neat.
• Injector is messy if you have a nullable instance (because you cannot NewType("my-type", None))
• Injector is messy in conjunction of mypy if you have multiples types for the same dependency slot that does not share parent class. For instance returning either str or FilePath.
• Documentation is lacking many examples, and clarification. But since the tool is very basic, you can learn pretty quickly.
• I’ve stumbled on a python 3.8 to 3.9 bug in conjunction of pydantic-settings that i’ve documented there.
• Only the SingletonScope is supported, but there are request for SessionScope
• Configuration is not supported as a feature, which is better if you are using Pydantic-settings after all.
• There is no proper support for CallableProvider, but you can access a value that run your routine and return None. Which is less that ideal.

You can see my migration in action there (unfortunately i’ve renamed some files so my « container » file cannot be diff simply):

• The new container definition witth injector
• The old container definition with PDI

[ngirard]

Wow... thank you so much @Guibod !
Much appreciated !

[jakub-borusewicz]

For anybody still looking for alternative, here is library that is designed as a replacement for dependency-injector
https://that-depends.readthedocs.io/