[Freeipa-devel] Proposal: Use argparse for option parsing

[Petr Viktorin]

On 10/12/2012 05:45 PM, Dmitri Pal wrote:
> On 10/12/2012 11:04 AM, Petr Viktorin wrote:
>> Hello,
>> I read through https://fedorahosted.org/freeipa/ticket/3060 and
>> noticed that the requirements are similar to what an existing library
>> offers.
>>
>> The optparse module we currently use for CLI option parsing is
>> deprecated[1]. The replacement is called argparse, which is part of
>> the Python 2.7 standard library. Out of the box, it provides several
>> features we either lack or had to handle manually, namely:
>> * supporting sub-commands [2]
>> * producing more informative usage messages [2]
>> * handling both optional and positional arguments [3]
>> * as well as including a number of other more minor improvements on
>> the optparse API. [3]
>>
>> The package has also been backported to Python 2.6, the only catch
>> there is that it's not in the standard library.
>>
>>
>> Not much of our code calls optparse directly, so switching shouldn't
>> be a major effort (within the scope of reorganizing the help system).
>> In exchange we get better CLI help messages, forward compatibility,
>> and reuse of proven code instead of our own solutions.
>>
>>
>> [1] http://docs.python.org/library/optparse.html
>> [2] http://code.google.com/p/argparse/
>> [3] yum info python-argparse (EPEL-6)
>>
> The ticket is IMO nice to have. Does it provide any value for other main
> commands?

Yes, it is nice to have. I thought that only affects priority, not what 
technical solution is correct.
I don't think there's value for other commands than help.

> If so can you reference other tickets that it would help with.
> I am not sure I want the switch for just help.

The help improvement ticket describes describes "sane" behavior for a 
subcommand-based CLI, which is what argparse was written for. We have 
our own implementation of it, which is subtly wrong, so we can either 
continue maintaining it or switch to reusing existing, tested code.
I think using the library is better in the long run. (And as a 
nice-to-have ticket, this is for the long run, right?)

-- 
Petr³