Isn't it bizarre how software developers have taken runtime DI to such extremes that it was considered a good idea to configure services in XML or YAML -- basically another language, that has to be parsed, can be malformed, etc?
$ ./my-server -reporting=email
vs
setting com.mycompany.package.subpackage.di.providers.abstract.ReportingProvider to com.mycompany.package.subpackage.di.providers.impl.EmailReportingProviderImpl.
The whole DI is a wrong concept. Dependencies should be instantiated at top level (main function) and explicitly passed down the call graph as interface instances.
DI breaks the call graph with (configurable) side effects. If you pass down dependencies explicitly you don't even need mocking frameworks for testing.
Passing dependencies also qualifies as DI and is for the benefit of the developer. Maybe you are only talking about DI frameworks or containers in which case I share some skepticism but in general the concept of DI is pretty sound.
The decision to use XML was actually quite reasonable for many developers given the constraints at the time. Thankfully Java has mostly seen the light these days, adding generics, first-class functions, and good-enough multiple inheritance (though it still has very restricted and cumbersome metaprogramming - classes are not first-class, and the lack of HKT makes it very difficult to work with functions generically since you can't abstract over arity), and people are gradually realizing that this different environment warrants different choices. (Companies still have terrible policies about code versus "config" though).
well, then how do you do it ? what do you do if your client / boss tells you "I want to configure the plug-ins & classes availables in the software through some file editing without having to recompile anything" and your codebase is in C++ / Java / Go / D / Rust ...
You compile all the (tested) combinations as static executables and shove them all into the release package.
But you might also encounter DI config files for specific environments, like development where you inject MockMailer, TrivialLogger and InMemoryDatabase instead of RealLifeMailer, CloudLogger and ActualDatabase.