MooseX::Getopt help without nagging

[Boldra]

I have a simple MooseX::GetOpt class:

package MXGOTest;
use Moose;
use 5.010;
with 'MooseX::Getopt';
has name => ( is => 'rw', isa => 'Str', required => 1);
sub run {
   say "NAME=" . shift->{name};
}
1;

but when I run with -? --man or --help I get reminded that I'm missing a required switch:

$ perl mxgotest.pl --help
Required option missing: name
usage: mxgotest.pl [-?] [long options...]
        -? --usage --help  Prints this usage information.
        --name

Is there a way to get the usage information without getting complaints about missing args?

Thanks

[stonecolddevin]

change

has name => ( is => 'rw', isa => 'Str', required => 1);

to

has name => ( is => 'rw', isa => 'Str' );

[bobr]

Hi,

MooseX::GetOpt just translates options to following call to Getopt::Long::Descriptive

use Getopt::Long::Descriptive;

my ($opt, $usage) = describe_options(
    'usage: mxgotest.pl [-?] [long options...]',
    [   'help|usage|?!' => 'Prints this usage information.' ],
    [   'name=s'        => 'Sets the name', { required => 1 } ],
);

The message is caused by required parameter. From the GLD docs:

If an option is required, failure to provide the option will result in describe_options printing the usage message and exiting.

I would remove the required from the name attribute and implemented the functionality after new_with_options call.

-- Roman

[Boldra]

Ok, then this looks to me like a bug in Getopt::Long::Descriptive . I want something that behaves more like standard unix utils like rm:

If I type just rm, I get a message that I'm missing a parameter AND the usage information. If I type rm --help I get the help information and no complaints.

In my simple example leaving required out might appear to be a solution, but in practice I might have four or six required arguments, and using moose features could save me about ten lines of code.

[TomDLux]

I have all the functionality in Moose module files, and then have a short .pl file to bring it all together.

prepaprse_args()
my $xyz = XYZ::ABC->new_with_options();   # obfuscated to protect my e
+mployment
$xyz->run();
__END__

In preparse_args I quickly scan the args for -man or --man, which I handle with pod2usage. I also accept '-man modules', in which case I print a list of all the custom modules in the program ... the non CPAN ones. With the request '-man XYZ::ABC.pm', I print the pod for that one module. This way I have access to user documentation as well as inner details.

[Boldra]

This looks like a good solution. I don't expect Getopt::Long::Descriptive will provide a fix, as I think it would involve an API change.

Thanks