The whole point of moving that to an attribute was to support lazy-loading commands to load only the command that is being run instead of all registered commands. This is indeed not compatible with configure the command dynamically.
What is your actual use case for that ?

This is for example to allow you to make aliases for several cities in the database, for example:
AsCommand('app:{city}:script1')
AsCommand('app:{city}:script2')
AsCommand('app:{city}:script3')

For example to filter Commands by city, permissions, etc.

I still don't understand the use case: if you have 2 cities in the database and you add 2 aliases app:city1:script1 and app:city2:script1, running the command will still run the same thing. So I don't see how this allows filtering by city.

Depending on the city the script does a different treatment, for example city1:script load a configuration in database for city1 and city2 another configuration.

@aleblanc how do you detect that ?

With $input->getArgument('command')

this won't be reliable. As Symfony supports shortening each part of the command name as much as you want as long as it is not ambiguous (meaning that there is only one command that has at least 1 name/alias that corresponds), you have no guarantee that the command argument will contain the full city name.
I would strongly suggest you to use a city argument instead.

@stof says:

I would strongly suggest you to use a city argument instead.

I fully agree. This is the right way for your use case.

Yes, I also agree with @stof. Make city an argument and run app:script1 city1 ... but of course you are right and if was working for you because you did not use the command shortening.
But just one thing I'm thinking about.

The whole point of moving that to an attribute was to support lazy-loading commands to load only the command that is being run instead of all registered commands. This is indeed not compatible with configure the command dynamically.
What is your actual use case for that ?

Does this mean we should remove the setAliases, because it's not working anymore this way? Or is it still removed / deprecate to use it this way?

Not all usages of symfony/console are using a container with lazy-loaded commands. This method is still useful in standalone usages.

I can see AsCommand attribute has $aliases parameter so I think OP should just use it instead of setAliases()

@javaDeveloperKid the problem is dynamic aliases.

@javaDeveloperKid the problem is dynamic aliases.

Right. I missed it.

In Application.php I can see there is a command loader which is a service locator. Maybe it could be decorated and the logic would be:

• if the locator has a command then return this
• if not then look ask the database for dynamic alias and then get the actual command from the service locator

I agree the use case is better addressed otherwise, as mentioned above.
The DX looks unfortunate though: ideally setting aliases at runtime on a lazy command should rise an error explaining the limitation/incompatibility. PR welcome in that direction.