Another solution is merging #22187 which allows to inject named arguments in all services of a file :)

Edit: with your example, it could look like:

services:
    bind:
        $argument1: '%kernel.project_dir%'
        $argument2: '%app.container_param%'
        $argument3: '%app.another_param%'
    # ...

    App\:
        # ...

This way you don't end up with hundreds of useless lines but you keep the advantages of being explicit and you don't inject a class that imo belongs to sf internals.

@GuilhemN yes, your proposal could work too ... although I don't like that it introduces yet another configuration option that users must learn.

There's not much to learn, the syntax is the same as arguments. The difference is that it can be used for arguments and method calls arguments and that its content doesn't need to be used in all services for resources/defaults.

This could replace arguments in most cases in fact so if you're worried there is too much to learn, we could reduce the explanations about arguments and method calls arguments to focus on it.

I was referring to bind, which would be the new keyword/option to learn.

@javiereguiluz why can't you already inject the parameter bag?

For sure but that's not much to learn, there are options that are far less useful imo that we still introduced and documented (configurators, shared).

@theofidry have you tested it? Because I can't make that work at all 😞

I guess you first have to register the ParameterBag as a service:

services:
    Symfony\Component\DependencyInjection\ParameterBag\ParameterBagInterface:
        factory: ["@service_container", getParameterBag]

@GuilhemN

Uncaught Symfony\Component\DependencyInjection\Exception\RuntimeException:
Unable to resolve service "Symfony\Component\DependencyInjection\ParameterBag\ParameterBagInterface":
method "Symfony\Component\DependencyInjection\ContainerInterface::getParameterBag()" does not exist.

What if you explicitly don't autowire this service?

@javiereguiluz, by injecting ParameterBag or the whole container you make dependencies of your class unclear. If you feel that you repeat the same tasks of declaring some classes' arguments again and again, shouldn't you consider refactoring?

What about introducing a ConfigurationClass? It takes all scalars you need, delivers them through getters, and should be autowirable

@javiereguiluz to be honest that's one thing I don't like about auto-wiring: bending designs to make it work better. IMO auto-wiring is a tool to help, not something you base your application on. So in your case I would say that yes: you inject scalar values, you need to manually wire them. And Symfony is not alone: even in frameworks with full auto-wiring like Laravel you need to do that.

Now if you really want to go that way:

• Inject the ParameterBag: dunno why that doesn't work but this doesn't sound right. Or maybe this has something to do with the compiled container... In any case it sounds like something that should be supported
• Have configuration classes as suggested as @NicoHaase
• Have a parameter alias to take advantage of [DependencyInjection] Add support for named arguments #21383
• Bind your parameters [DependencyInjection] Support local binding #22187

There may be other solutions like refactoring some pieces, using abstract service definitions, but hard to tell without your code.

#22187 is exactly the solution we created to solve this issue, I think we just need everyone to focus on it so that it gets some support and is merged.

#22187 is just the explicit way to code your own conventions in configuration. Contrary to a proposal like this one, or the annotation based ones, that force you to design/write your code in some way for the need of auto-configuration, which is doing things reverse side to me.

Let's close this in favor of #22187. Thanks!

I think this approach to improve development speed is important. Because to add an argument in a service I need to move to other file, search service (or create his definition), add argument, when I back to my service I lost my focus for this repetitive tasks and if the project is huge it is worst....

This kind of things is not magic is to be efficient...

I know all symfony programmers must know how services system works but in 90% of time we need to save our time.

This problem is the same to add a "TAG", "priorities" ... in a service. What do you think about the use of Annotations?

See #25288, which could be used instead.