Hey!

Thanks for your PR. You are targeting branch "7.4" but it seems your PR description refers to branch "7.4 for features".
Could you update the PR description or change target branch? This helps core maintainers a lot.

Cheers!

Carsonbot

Attributes attached to the invokable class are lost by the time we have aCommand added to the Application.

Can you elaborate on this? Why are they lost?

Also: Pleasealways provide tests that cover your change.

@derrabus - I added a hyperlink to the OP explaining whats meant by "wrapping command". Let me know if its still unclear.

If anyone can suggest an existing test to modify, I will do so.

I don't understand whyyou need to access attributes of the wrapped invokable commandfrom the actualCommand class. Attributes should not be read at runtime (for performance). You can create an autoconfiguration mechanism to read the attributes during container compilation and inject them into a service.

Jérôme has a good point about manipulating the command at compile time instead of runtime. When accessing the service you get the real instance .

Let me know if its still unclear.

It is. Your link is pointing to some line in our codebase, but that line does not explain your use-case. It neither tells me what you're trying to achieve, nor why you want to do that, nor how you tried to do that.

If anyone can suggest an existing test to modify, I will do so.

This is a new feature, which means we need new tests. You can have a look at the existing test suite for inspiration, but we won't write those tests for you. And we won't merge a new feature without any tests.

Apologies for not including my use case originally. I'm no Symfony expert, so your expertise here is much appreciated.

I'm the maintainer ofDrush, the CLI for Drupal. Drush is a happy user of thestandalone Console component.

I am exploring using Invokable Commands in our next version. Symfony made this possible in May in#60394. Drush has no command services at this time, so the suggestion to read Attributes at compile time won't work. We need a runtime solution, and so will other standalone Console users. We could read the Attributes as we add commands to the Application, but then we would have to store them separate from the Command object. Or we would have to extend Command and add a method to get the callable with its Attributes. That feels awkward enough that we wouldn't support Invokable Commands which is a shame IMO - they are great.

Thanks for the context.

I see that Drush is built withconsolidation/annotated-command. Looking atits documentation for theFieldLabels andDefaultFields attributes, it looks very close to what we built with invokable commands. I do think that the two attribute systems (Symfony and Consolidation) are mutually exclusive to configure the command.

We are working to remove the dependency on consolidation/annotated-command in favor native Symfony Console conventions. Seedrush-ops/drush#6135. This Console PR is part of the effort.

Symfony Console supports a few Attributes like AsCommand and Argument and Option - we need a lot more in Drush. We can add declare Attribute classes and add them to our Invokable Commands but we can't cleanly read the Attributes - thus this PR.

FYI, I removed the return type hint to an Internal class.

I have added tests to the PR. I'm getting a failure because I removed the return type hint to an internal class. How can we best resolve this?

So, do we think this is solvable for us and other standalone Console users? I hope so.

I think I've addressed all feedback. The one test failure is unrelated to this PR.

Changelog entry added.

Test failure looks unrelated.

Getter namegetCode looks like status code. Those were my initial thoughts when I read the PR title.

Getter namegetCode looks like status code. Those were my initial thoughts when I read the PR title.

This name matches the existingsetCode. If it was returning the status code, we would name itgetStatusCode.