Getopt::TooMany: looking for a perfect CLI processor

Dallaylaen has asked for the wisdom of the Perl Monks concerning the following question:

Hello dear esteemed monks,

While Getopt::Long is a great module, I started noticing it lacks some features, like help generation or ability to stop processing arguments on first non-option. So I looked at cpan search for "getopt" at https://metacpan.org/search?q=getopt and I'm overwhelmed by the number of modules that are already there.

What I would like to get is (apart from just "processing the command line the way Getop::Long does"):

1. Generating help on the fly (Getopt::Helpful does that but seems unmaintaned);

2. Object-oriented interface via instantiation and accessors/mutators, not inheritance:

    my $cli = Getopt::Something->new(
        "Usage: $0 [options] <file> ...",
        [ "x|expect=s", \@except, "<pattern> Add an exception" ],
        ...
    );
    $cli->stop_on_argument( 1|0 );
    $cli->run(); # or $cli->run( \@array ); if not @ARGV
[download]

3. I would love to add any other features I find missing.

So what are the latest and greatest members of Getopt:: Family? Thank you.

Comment on Getopt::TooMany: looking for a perfect CLI processor Download Code

Replies are listed 'Best First'.
Re: Getopt::TooMany: looking for a perfect CLI processor by stevieb (Canon) on Sep 06, 2019 at 22:15 UTC
Perhaps Getopt::Long Object Oriented Interface.	[reply]
Re^2: Getopt::TooMany: looking for a perfect CLI processor by Dallaylaen (Chaplain) on Sep 10, 2019 at 13:13 UTC
Haven't seen this one, thank you.	[reply]
Re: Getopt::TooMany: looking for a perfect CLI processor by swl (Parson) on Sep 07, 2019 at 00:32 UTC
I've been using Getopt::Long::Descriptive for a while with decent results. I don't know if it does all you want, i.e. it has accessors but perhaps not mutators, but it can return errors on missing args in the opt_spec array.	[reply]
Re^2: Getopt::TooMany: looking for a perfect CLI processor by Dallaylaen (Chaplain) on Sep 10, 2019 at 13:13 UTC
Well, it does answer my question as a whole. Thank you.	[reply]
Re: Getopt::TooMany: looking for a perfect CLI processor by rjt (Curate) on Sep 07, 2019 at 08:27 UTC
For help generation and better error handling, Pod::Usage has been in my toolbox for a long time. It will pull the help right from your perldoc POD. (Which you were hopefully going to write anyway, so it's no extra work.) It is configurable as to which sections it will pull and display when help is needed. Your point #2 has me confused. Why is that important, as long as the interface is well designed and documented? Point #3, there are indeed a lot of features from `Pod::Usage` and the plethora of `Getopt::` modules you've seen. None that I know you need though. (And none that I use on a regular basis.)	[reply] [d/l] [select]
Re^2: Getopt::TooMany: looking for a perfect CLI processor by Dallaylaen (Chaplain) on Sep 10, 2019 at 13:10 UTC
I don't know, somehow I prefer to have option descriptions close to the declarations. A POD is (hopefully) a comprehensive manual with detailed explanations, whereas `--help` is just a quick reminder for those who can't keep all the options in their head. Maybe I'm wrong and will change my mind later. #2 is merely avoiding namespace pollution (via lots of exported functions - easy to forget or hit a collision), @ISA clutter (when one has to extend a Getopt:: class - I've seen that a couple times on CPAN), and awkward syntax (`local $Foo::Bar::VariableName = $Foo::Bar::VariableName + 1` is a cool feature, but let's use it when it's needed). Oh and thanks for mentioning Pod::Usage, I didn't know of that one.	[reply]


Perl Monk, Perl Meditation
	PerlMonks