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

[Dmitri Pal]

On 10/15/2012 09:05 AM, Petr Viktorin wrote:
> 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?)
>
Since there is not value for other commands I do not see an urgency to
switch now. The homegrown solution might be ugly but it works so
replacing it would not be a high priority. 3.2 is already pretty full
and I do not see this work getting in.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/