gh-58573: Fix conflicts between abbreviated long options in the parent parser and subparsers in argparse - #124631

… parent parser and subparsers in argparse (pythonGH-124631)

Check for ambiguous options if the option is consumed, not when it is
parsed.
(cherry picked from commit 3f27153)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

… in the parent parser and subparsers in argparse (pythonGH-124631)

Check for ambiguous options if the option is consumed, not when it is
parsed.
(cherry picked from commit 3f27153)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

…e parent parser and subparsers in argparse (GH-124631) (GH-124759)

Check for ambiguous options if the option is consumed, not when it is
parsed.
(cherry picked from commit 3f27153)

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

In Python 3.13 and 3.12.7, the behavior of _parse_optional has
changed. It used to raise an error on multiple matching actions
itself, and only ever return None or an option tuple. Now the
"raise error on multiple matching actions" code was moved out
into consume_optional, and _parse_optional returns either None
or a *list* of option tuples, which contains more than one if
multiple actions match. See:

python/cpython#124631
python/cpython#58573

This adapts to the change in a way that should work on both older
and newer Pythons. I re-implemented the handling of multiple
matching options so we don't have to worry about licensing and
attribution if we copied in upstream's version.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

In Python 3.13 and 3.12.7, the behavior of _parse_optional has
changed. It used to raise an error on multiple matching actions
itself, and only ever return None or an option tuple. Now the
"raise error on multiple matching actions" code was moved out
into consume_optional, and _parse_optional returns either None
or a *list* of option tuples, which contains more than one if
multiple actions match. See:

python/cpython#124631
python/cpython#58573

This adapts to the change in a way that should work on both older
and newer Pythons.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

In Python 3.13 and 3.12.7, the behavior of _parse_optional has
changed. It used to raise an error on multiple matching actions
itself, and only ever return None or an option tuple. Now the
"raise error on multiple matching actions" code was moved out
into consume_optional, and _parse_optional returns either None
or a *list* of option tuples, which contains more than one if
multiple actions match. See:

python/cpython#124631
python/cpython#58573

This adapts to the change in a way that should work on both older
and newer Pythons.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

In Python 3.13 and 3.12.7, the behavior of _parse_optional has
changed. It used to raise an error on multiple matching actions
itself, and only ever return None or an option tuple. Now the
"raise error on multiple matching actions" code was moved out
into consume_optional, and _parse_optional returns either None
or a *list* of option tuples, which contains more than one if
multiple actions match. See:

python/cpython#124631
python/cpython#58573

This adapts to the change in a way that should work on both older
and newer Pythons.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

In Python 3.13 and 3.12.7, the behavior of _parse_optional has
changed. It used to raise an error on multiple matching actions
itself, and only ever return None or an option tuple. Now the
"raise error on multiple matching actions" code was moved out
into consume_optional, and _parse_optional returns either None
or a *list* of option tuples, which contains more than one if
multiple actions match. See:

python/cpython#124631
python/cpython#58573

This adapts to the change in a way that should work on both older
and newer Pythons.

NOTE: This includes the fix for the typo that is in a separate commit on
master.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
Signed-off-by: Brian C. Lane <bcl@redhat.com>

Resolves: RHEL-61426

…e parent parser and subparsers in argparse (GH-124631) (GH-124760)

Check for ambiguous options if the option is consumed, not when it is
parsed.
(cherry picked from commit 3f27153)

Windows CI fails to parse its own command line:

  colcon: error: unrecognized arguments: -DBUILD_TESTING=ON
  --no-warn-unused-cli -DINSTALL_EXAMPLES=OFF -DSECURITY=ON
  -DAPPEND_PROJECT_NAME_TO_INCLUDEDIR=ON

argparse will not pass option-looking tokens to an nargs='*' option, so
colcon overrides argparse's internal _parse_optional() to make
'--cmake-args -DFOO=BAR' work at all (bpo-9334).  The override detects the
"argparse could not classify this" case by comparing against the exact
value _parse_optional() returns, and python/cpython#124631 changed that
value to a list of tuples.  On Python 3.14 the comparison stops matching,
so the override silently does nothing, every -D argument is classified as
an unknown option, and none of them reach --cmake-args.

colcon-core 0.18.2 added the list form to that comparison.  The existing
<0.18 ceiling excluded every release that carries the fix, which is what
turned the 3.14 bump into a build failure.

Verified against the exact CI command line on Python 3.14.3: 0.17.1
collects cmake_args=[] and reports the arguments as unrecognized, while
0.18.2 and 0.21.1 both parse them correctly and exit 0.  The range
resolves to 0.21.1, and the full environment solves for win-64 and
linux-64.

Do not re-cap this at the next minor version.  A tight ceiling on a
tooling dependency is what held the fix out of reach here, and the comment
above this block already says these are pinned loosely on purpose.