[bug] Running multiple commands via the CLI v2 API raises ArgumentError

[fschoenm]

Environment details

• Operating System+version: Ubuntu
• Compiler+version: n/a
• Conan version: 2.0.6
• Python version: 3.11

Steps to reproduce

I'm trying to run conan via the CLI API to programmatically create packages. I used the CLI API like @memsharded recommended in #13065 because the low level API seems to be too complex for our use case.

However, there's apparently a problem with Conan's argument parser that seems to be reused for some reason.

Here's a small reproduction example with a simpler command (list) but the create subcommand has the same issue:

from conan.api.conan_api import ConanAPI
from conan.cli.cli import Cli

conan_api = ConanAPI()
conan_cli = Cli(conan_api)
conan_cmd = ["list", "*"]

conan_cli.run(conan_cmd)
conan_cli.run(conan_cmd) # second .run() call leads to the argparse error.

Logs

Gives the following error when run the second time:

Traceback (most recent call last):
  File "./conan_bug.py", line 9, in <module>
    conan_cli.run(conan_cmd)
  File "/home/build/.local/share/virtualenvs/detectors-1VqckO79/lib/python3.8/site-packages/conan/cli/cli.py", line 172, in run
    command.run(self._conan_api, self._commands[command_argument].parser, args[0][1:])
  File "/home/build/.local/share/virtualenvs/detectors-1VqckO79/lib/python3.8/site-packages/conan/cli/command.py", line 134, in run
    info = self._method(conan_api, parser, *args)
  File "/home/build/.local/share/virtualenvs/detectors-1VqckO79/lib/python3.8/site-packages/conan/cli/commands/list.py", line 99, in list
    parser.add_argument('-p', '--package-query', default=None, action=OnceArgument,
  File "/usr/lib/python3.8/argparse.py", line 1398, in add_argument
    return self._add_action(action)
  File "/usr/lib/python3.8/argparse.py", line 1761, in _add_action
    self._optionals._add_action(action)
  File "/usr/lib/python3.8/argparse.py", line 1602, in _add_action
    action = super(_ArgumentGroup, self)._add_action(action)
  File "/usr/lib/python3.8/argparse.py", line 1412, in _add_action
    self._check_conflict(action)
  File "/usr/lib/python3.8/argparse.py", line 1551, in _check_conflict
    conflict_handler(action, confl_optionals)
  File "/usr/lib/python3.8/argparse.py", line 1560, in _handle_conflict_error
    raise ArgumentError(action, message % conflict_string)
argparse.ArgumentError: argument -p/--package-query: conflicting option strings: -p, --package-query

[fschoenm]

You can see, the second conan run complains about already registered arguments in the parser.

Even recreating the API and CLI objects does not help. The following code has the same issue:

from conan.api.conan_api import ConanAPI
from conan.cli.cli import Cli

conan_api = ConanAPI()
conan_cli = Cli(conan_api)
conan_api2 = ConanAPI()
conan_cli2 = Cli(conan_api2)

conan_cmd = ["list", "*"]

conan_cli.run(conan_cmd)
conan_cli.run(conan_cmd)

[memsharded]

Hi @fschoenm

I think this is expected. The Cli() object is not designed to be reused. It represents a single command line invocation, each time will take care of the parsing. The ConanAPI is the thing that can be reused among calls, but the Cli() object can't be reused for multiple calls.

The initial planning was to document and release the ConanAPI, but not so sure about Cli itself.

[fschoenm]

@memsharded Please see my first comment above. Even recreating the Cli object didn't help.

[memsharded]

Oh, thanks for clarifying. We will check it.

[memsharded]

This has been fixed in #14053, and will be in 2.0.7.

Note, however, that the Cli class is not public and is not documented, so it is subject to breaking changes at any time.
We cannot guarantee that we will make it public, and it is possible that it will never be documented, and instead the ConanAPI learns higher level primitives, we don't know yet.

[fschoenm]

@memsharded I see. I guess that's fine as long as you introduce a higher-level API. The low-level API primitives look really scary to re-implement without knowing too much about Conan internals.

Just FYI, we're using it for automatically creating packages for multiple configurations and querying information from the conanfile and the dependency graph. It's stuff that could not be easily or reliably done via shell scripting due to parsing and multiple conanfiles being involved but from a Conan standpoint it would be really high-level.

Thanks for the quick fix!

[memsharded]

The low-level API primitives look really scary to re-implement without knowing too much about Conan internals.

Yeah, we know it. It will improve when we really start documenting it, but still we have to discuss what kind of high-level interface is the best. Thanks for the feedback!