The build on 2.7 is currently broken which explains the failing PR, I will rebase when it is fixed. Locally tests are passing.

Honestly, I don't understand why we can't (re)use existingCommand->code (Command::setCode) for lazy-loading purpose. Do I miss something?

Anyway, I definitely like to see separateCommandConfiguration class, but it would be great to have immutable object without command dependency.

Honestly, I don't understand why we can't (re)use existing Command->code (Command::setCode) for lazy-loading purpose. Do I miss something?

Yes it's possible but I consider it a cheap workaround rather than a solution. With that you would have to write commands that do not extend theCommand class, you couldn't use helpers for example. And you can't implementinitialize() orinteract().

Instead of putting the command out of theCommand class, I'd rather put the configuration out of theCommand class ;) (makes more sense)

but it would be great to have immutable object without command dependency.

I don't I understand that part sorry?

With that you would have to write commands that do not extend the Command class

Why? Closure can resolve command and execute it:

$command =new newCommand(null,$configuration);$command->setCode(function ($input,$output,$configuration) {// Feel free to resolve command instance from DI container$internal =newGreetCommand(null,$configuration);return$internal->run($input,$output);});

You can add this 3rd argument without breaking BC.

I don't I understand that part sorry?

I'd like to see a value object, not a mutable one.

@unkind Your example is a workaround. That's also the kind of workaround I have implemented for using inPiwik and we are not using it yet (and not released) because "it's not the Symfony API so people have to learn the Piwik console version (and we have to maintain it)".

So yes of course you can always find a way, but here I'm suggesting to improve Symfony Console to have an easy and clean solution available for everyone instead of releasing a "fork" (or rather alternative to symfony/console).

Your example is a workaround

I don't state it isn't. The only thing I don't like in your one is thatCommandConfiguration (meta data) depends on$command instance (or factory). It's likeRoute holds$controller instance (or factory).

AFAIK, Symfony 2.7 is already closed for new features according tohttp://symfony.com/doc/current/contributing/community/releases.html. If it isn't, I can make alternative PR. However, I don't see much sense in these workarounds for 3.0.

2.7 will not accept any new features at the end of the month, so we still have time.

@unkind Ah you meanCommandConfiguration::getCommand()?

Yes I don't find this perfect too and I'd rather introduce aCommandResolver like theControllerResolver. However when I suggested that in the original issue (edit: rather I read it somewhere else) I could sense that people where not really keen on "overengineered" solutions (which I don't think it is) so that's why I went this this simple one. If there's more chance for a PR with aCommandResolver then I'll gladly add it.

@mnapoli by the way, you should removeCommand::isEnabled().

@mnapoli what is the status of this pull request ?

@mickaelandrieu it is waiting for some love :)

I.e. waiting for a core team member to tell me:

• never going to happen
• want to merge this PR but X or Y needs to be fixed
• discuss alternate implementation, I'm open to implement it differently if needed

I would prefer a way staying closer to the current architecture, as I explained in#13989 (comment) as well

@stof OK I can try a different approach, just to be clear the name and aliases would have to be defined outside the command right?

Here is a solution using callbacks as a factory:

$callable =function ($commandName) {// return the command instance};$app->addLazyCommand('name', ['aliases'],$callable);

Or we could introduce aCommandResolver like theControllerResolver:

interface CommandResolver {publicfunctiongetCommand($name);}$app->setCommandResolver($resolver);$app->addLazyCommand('name', ['aliases'],'command-id');

Thoughts before I go with an implementation?

👍

Any update on this? I'm having major issues right now due to aSoapClient being a dependency of a command. Due to the nature of how the php soap client works, it fails writing the wsdl into the cache with parallel running processes. Because running 1 command, triggers loading the dependencies of all, this fails and crashes.

The only way I can fix it is by fetching the soap service from the container at a later stage and this is something I'm hoping to avoid.

/ping@mnapoli

On my side I have nothing new to add here, I opened the PR and also offered alternative ideas for implementations so I'm waiting for feedback ;)

And since I opened this PR I keep seeing this problem more and more, for example onPiwik as we introduce dependency injection more and more.

@iltar For now, you coulddeclare the SoapClient service lazy, can't you?

@xabbuh it's an option but I actually wrote my own interfaced wrapper for it, which in turn is a nicer solution than it originally was by calling the SoapClient directly. I don't like introducing lazy services via that package as the generated proxies provide some obstacles.

The php SoapClient is just bad by design.

What state is this in?

👍

Have a look also at#22734 which seems to be a very good solution (maybe better than this one because simpler).

Closing since a better approach is being worked on.

@nicolas-grekas Could you link that one please?

@TomasVotruba I think he was referring to#22734

@theofidry I prefer links over guessing. Thanks.

🎉 thanks@chalasr