[PATCH 0/9] argument parsing fixes and improvements

[Jani Nikula]

On Mon, 25 Sep 2017, David Bremner <david at tethera.net> wrote:
> Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
>> So from an implementation point of view, it's definitely cleaner/simpler
>> to have an internally "explicitly unset" state for the CLI flags.
>
> I'm trying to separate-out/defer impliementation questions here, at
> least until I'm clear on the UI.

Patches 1-5 and 8 in this series would be non-committal refactoring and
cleanup in the mean time. ;)

>> From a CLI UI perspective: do we want to be able to send --foo=default
>> for a boolean explicitly?
>
> I have the feeling that maybe Jani does, but I'm not sure (as sometimes
> happens) why my way of thinking about it isn't the only obvious way ;).

I'm undecided. Definitely maybe. Going by "worse is better", the
implementation *does* impact the decision, at least it impacts my
opinion. For example, I don't think we'll open the database before
argument parsing even if that turned out to be "the right thing".

Looking at the defaults from another angle, if we don't want the ability
to set --foo=default explicitly, I still think passing ints as booleans
to the argument parser and checking if a boolean is neither true nor
false is the wrong thing to do. I'd also like to convert to stdbool
more. But those should not be a reason to convert essentially boolean
arguments to keyword arguments. I think we need a way to have the
argument parser tell us if an argument was present or not.


BR,
Jani.