Repository: conda/conda

Issue:
`cli.python_api` captures `stdout` from `cli.common.confirm_yn`
`cli.python_api.run_command` captures any output to `stdout`/`stderr` via `common.io.captured`. This causes the user confirmation messages from `cli.common.confirm_yn`, i.e.,
```bash
Proceed ([y]/n)? 
```
to also be captured, i.e., not being output/accessible until the command finishes (which might be never if the user does not interact). The examples in the doc string are
```python
    Examples:
        >>  run_command(Commands.CREATE, "-n newenv python=3 flask", use_exception_handler=True)
        >>  run_command(Commands.CREATE, "-n newenv", "python=3", "flask")
        >>  run_command(Commands.CREATE, ["-n newenv", "python=3", "flask"], search_path=())
```
and show exactly such use cases.

Due to this, `run_command` is only generally usable if any of `--json`, `--yes` or `--dry-run` is supplied.
There could be two solutions to this:
  1. Force the user to include at least one of those arguments.
  2. Instead of only capturing the output, it could be recorded but also forwarded to `stdout`/`stderr`. This could/should be made optional via some `kwarg` for `run_command`.

Possibility 1. is of course much simpler and could at least serve as a temporary solution.
`cli.python_api` captures `stdout` from `cli.common.confirm_yn`
`cli.python_api.run_command` captures any output to `stdout`/`stderr` via `common.io.captured`. This causes the user confirmation messages from `cli.common.confirm_yn`, i.e.,
```bash
Proceed ([y]/n)? 
```
to also be captured, i.e., not being output/accessible until the command finishes (which might be never if the user does not interact). The examples in the doc string are
```python
    Examples:
        >>  run_command(Commands.CREATE, "-n newenv python=3 flask", use_exception_handler=True)
        >>  run_command(Commands.CREATE, "-n newenv", "python=3", "flask")
        >>  run_command(Commands.CREATE, ["-n newenv", "python=3", "flask"], search_path=())
```
and show exactly such use cases.

Due to this, `run_command` is only generally usable if any of `--json`, `--yes` or `--dry-run` is supplied.
There could be two solutions to this:
  1. Force the user to include at least one of those arguments.
  2. Instead of only capturing the output, it could be recorded but also forwarded to `stdout`/`stderr`. This could/should be made optional via some `kwarg` for `run_command`.

Possibility 1. is of course much simpler and could at least serve as a temporary solution.


Discussion:
Definitely prefer option 1 if anybody wants to swing by and submit an easy PR.
Definitely prefer option 1 if anybody wants to swing by and submit an easy PR.

Resolving patch:
diff --git a/conda/cli/python_api.py b/conda/cli/python_api.py
--- a/conda/cli/python_api.py
+++ b/conda/cli/python_api.py
@@ -35,7 +35,10 @@ def get_configure_parser_function(command):
 
 
 def run_command(command, *arguments, **kwargs):
-    """
+    """Runs a conda command in-process with a given set of command-line interface arguments.
+
+    Differences from the command-line interface:
+        Always uses --yes flag, thus does not ask for confirmation.
 
     Args:
         command: one of the Commands.X
@@ -67,6 +70,7 @@ def run_command(command, *arguments, **kwargs):
     split_command_line = split(command_line)
 
     args = p.parse_args(split_command_line)
+    args.yes = True  # always skip user confirmation, force setting context.always_yes
     context.__init__(
         search_path=configuration_search_path,
         app_name=APP_NAME,


Test patch: