Re: mailgw argument parsing

In message <[email protected]>,
Ralf Schlatterbeck writes:
>On Wed, Nov 23, 2022 at 09:07:18PM +0100, Ralf Schlatterbeck wrote:
>
>> So I see two changes to do
>> - Fix calls to usage in roundup_mailgw
>> - make args a tuple again
>
>I've pushed these.

Thanks. So now all we have is:

  - And further discuss positional args vs. options.

Positional args! raa raa raa!!! (raa is a cheer 8-)).

As you said this setup is usually a one time thing. Set and forget.
If it was being typed often on the command line, I would agree more
with these being set using options. I agree in general that having
labeled parameters is a good thing.

The best of both worlds would be similar svn or git (can't believe I
just typed that).

  command --global-options subcommand --sub-command-options

where the source is the subcommand. So:

    roundup_mailgw.py [-h] [-v] [-c DEFAULT_CLASS] [-S SET_VALUE]

              pops [-m mailbox] user:password@server
or
	      imaps_oauth -I OAUTH_CLIENT_ID
	                 [-O OAUTH_DIRECTORY]
                         [-T OAUTH_TOKEN_ENDPOINT]
			 [-m mailbox]
                         -s server -u user 

   optional arguments:

     -I OAUTH_CLIENT_ID, --oauth-client-id OAUTH_CLIENT_ID
       ...

and so on. (Yes, I know that -I is required, there is a bug about how
argparse help reports required args.)

Supposedly argparse can handle this subcommand structure.  However
this subcommand structure is off in the future.

I claim using positional parameters now makes it easier to support
both positional and sub-options form in the future.  I hope argparse
is smart enough to be able to distinguish -I either before or after
the subcommand, so this may not be a very strong argument.

I guess my opposition just comes down to mixing arguments for one
subcommand into the global arguments seems icky.  Similar to how
mixing the transfer/authentication mechanism into the source protocol
(imaps_cram, or pop vs pops ...)  was expedient but ... seemed off
somehow.

As an aside, it would be nice to be able to configure the path to
.netrc. Currently it is stuck at ~roundupuser/.netrc. We could add a
global -P option to set the path to the .netrc equivalent so it is
inside the tracker homedir for example. If we could get some
additional developers that would be a great starter ticket. I keep
meaning to do get us into the yearly hacktoberfest, but haven't really
had any luck.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.