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 !