--no option removed

[danepowell]

It appears that the --no parameter (non-interactive, assume no to all prompts) has gone through a lot of refactoring lately:
2b12e16
e306457

The current state is that it is documented as a valid parameter here:
https://github.com/drush-ops/drush/blob/master/src/Application.php

But if you actually try to use it, you get this error:

[Symfony\Component\Console\Exception\RuntimeException] The "--no" option does not exist.

[greg-1-anderson]

That comment in Application.php was notes, not documentation. It was out of date; I removed it in the documentation PR I am working on, #3010.

I don't know that --no will be coming back. Symfony does not support --yes and --no with the same meaning that Drush formerly did. Instead, we have --no-interaction aka -n which means "answer all prompts with their default value". This is closer to --yes, so we currently map yes to -n.

The documentation for the global options can be found in drush topic global. I just noticed that drush topic is including each topic in the list twice, but that's a separate issue.

[danepowell]

BLT is using cex --no in Drush 8 to test whether active and stored configuration is identical.

If --no is going away in Drush 9, it appears there's no way to handle this use case in Drush 9. It seems like the next best option would be to refactor drush cex to support --simulate, would you agree?

Running drush cex --simulate with Drush 9 right now produces this, even though drush cex alone works fine:

[Symfony\Component\Console\Exception\CommandNotFoundException]
Command "cex" is not defined.

[greg-1-anderson]

I think the solution here is to support config-status from your PR #2716 in both Drush 8 and Drush 9.

I would like to support --no, but even if we did make a wrapper set of user input helpers that supported this, any external Symfony-based libraries that we pulled in would be using the standard Symfony input helpers, which would lead to inconsistent behavior.

[danepowell]

It appears that --yes doesn't behave exactly the same as --no-interaction, see acquia/blt#2150

Additionally, if --yes does behave exactly the same as --no-interaction, that's going to be problematic since we won't be able to force a site install (previously, drush si --yes)

I'll try to investigate and open new issues for each of these as appropriate, unless you think I'm missing something obvious.

[greg-1-anderson]

Per #3082, maybe we can bring --no back. However, it might be confusing if -n was different than --no, so maybe not. Shrug.

[danepowell]

I no longer need --no, since we've added config-status. But I do need --yes for site-install. Other folks might have different use cases obviously.