Replace deprecated optparse dependency [RHELDST-34542]

[dichn]

No description provided.

[dichn]

re-pushed for adding the unit test for covering CommandOptionParser.

[dichn]

@rbikar ready for code review.

[rbikar]

@dichn

it looks good to me, since this is backwards incompatible change, in order to deploy new version of kobo, we would need to update rcm-pub code before that. Also other applications that build on kobo command interface.

Also I'd like to ask @kdudka to have a look. This may be potentially breaking change for some other applications.

[kdudka]

@rbikar Good point. I have quickly looked into OpenScanHub code and we use parser.add_option(...) on many places: https://github.com/openscanhub/openscanhub/tree/main/osh/client/commands

@siteshwar @sfowl What do you think? Should we migrate OSH and coordinate it with this change in kobo?

[siteshwar]

@siteshwar @Sfow

Is this change going to break osh-client? If not, I would not care too much about it.

[kdudka]

Is this change going to break osh-client?

Yes, osh-client will need to be migrated, too.

OshCommand is inherited from kobo.cli.Command and it accesses self.parser, which will be an object of a different type when these changes are applied.

[sfowl]

if this a breaking change, perhaps we should set a max version of kobo-client to buy us some time? e.g.

@ -43,6 +43,7 @@ It consists of central hub, workers and cli client.
 Summary: OpenScanHub CLI client
 Requires: koji
 Requires: python3-kobo-client >= 0.15.1-100
+Requires: python3-kobo-client <= 0.38.0
 Requires: %{name}-common = %{version}-%{release}

[kdudka]

@sfowl This would ensure that osh-client would not traceback at run time because of this. However, Fedora and EPEL do not maintain multiple versions of a single package at a time. So once a newer version of kobo lands into stable Fedora and EPEL repos, users will not be able to install osh-client any more. For users who have osh-client already installed, dnf will refuse to upgrade kobo on their system (assuming they updated osh-client before new kobo is available).

[rbikar]

@kdudka
I think that we don't have hurry with this change, but what we can do - is to keep backwards compatibility so we don't break other software that inherits from kobo.cli.Command and let maintainers to move to newer argparse variant at their own pace.

[kdudka]

As I understand it, this would mean to maintain both the implementations in kobo in parallel during the transition period. Definitely easier for us...

[dichn]

@rbikar
Switching to argparse changed the structure of the parsed options, causing rcm-pub to hit an AttributeError where optparse would have exited earlier with SystemExit.

~/src/rcm-pub$ pytest
FAILED tests/integration/client/test_cmd_clear_repo.py::TestCmdClearRepo::test_command_options - AssertionError: Expected SystemExit but got <class 'AttributeError'>
FAILED tests/integration/client/test_cmd_clear_repo.py::TestCmdClearRepo::test_command_options_quay - AssertionError: Expected SystemExit but got <class 'AttributeError'>
FAILED tests/integration/client/test_cmd_clear_repo.py::TestCmdClearRepo::test_command_successful - AssertionError: Expected SystemExit but got <class 'AttributeError'>
FAILED tests/integration/client/test_cmd_clear_repo.py::TestCmdClearRepo::test_command_successful_quay - AssertionError: Expected SystemExit but got <class 'AttributeError'>
...
========= 156 failed, 497 passed

I will file a JIRA for this in rcm-pub's unit tests: RHELDST-35465

[dichn]

Convert it to a draft to prevent accidental merging.

[rbikar]

@dichn
Can you check how difficult it would it support both optparse and argparse implementations at one time so we don't push other users to switch to argparse?