Required arguments
krlmlr opened this issue · 8 comments
Is there a way to specify required arguments and have parse_args exit with an error and a help message if these args are missing?
No, not in the optparse package (but if you really want it I'm pretty sure this feature exists in the package argparse if you don't mind the Python dependency).
In optparse you have to impose the requirement indirectly like the example in the package vignette with positional arguments :
arguments <- parse_args(parser, positional_arguments = TRUE)
opt <- arguments$options
if(length(arguments$args) != 1) {
cat("Incorrect number of required positional arguments\n\n")
print_help(parser)
stop()
} else {
file <- arguments$args
}
Thanks. I just noticed that my question is unclear -- I'm interested in required options, e.g., such with default unset. This call should return an error:
parse_args(OptionParser(option_list=list(make_option(opt_str=c("-c", "--c-long"), dest="C", action="store"))),
list())
I understand that this is not possible to do without breaking backward compatibility, but perhaps a flag to parse_args could enable this?
Do you have a practical use case where required optional arguments add alot of value compared to using the required positional arguments you can already use with argparse? I'm not a huge fan of expending energy replicating features that has already been implemented elsewhere:
suppressPackageStartupMessages(library("argparse"))
parser <- ArgumentParser()
parser$add_argument("c_long", nargs=1)
args <- parser$parse_args()
print(args)
And calling from command line missing required argument:
trevorld@siductionbox:~$ Rscript test.r
usage: test.r [-h] c_long
test.r: error: too few arguments
Calling with required argument present:
trevorld@siductionbox:~$ Rscript test.r 15
$c_long
[1] "15"
I do have a practical use case -- a script that needs a source directory. Of course this doesn't have to be a named parameter, but such cases are conceivable, too.
I am kind of worried by the Python dependency of argparse, and prefer a pure R solution. Would you consider merging a pull request for such a feature, if I came up with one?
The authors of the original python package whose API I mimic thought
nonoptional options weren't a good idea as it violates standard Unix design
patterns ( a discussion provided here
http://docs.python.org/2/library/optparse.html ).
However if you added a new argument to add_option and make_option after
metavar called unoptional_option defaulting to FALSE and added a
couple of tests to the unit tests where it is set to TRUE which don't end
up calling quit (else CRAN might complain) and it pases R CMD check then
I would consider merging a pull request for such a feature since it
shouldn't break backwards compatibility and at least one person finds it
useful.
Right now options without a default that aren't passed in don't exist in
the output list so you should just need to loop over the options in the
OptionParser which are unoptional and test whether they exist and if not
call the print_help method and quit.
On Fri, Nov 8, 2013 at 2:08 PM, Kirill Müller notifications@github.comwrote:
I do have a practical use case -- a script that needs a source directory.
Of course this doesn't have to be a named parameter, but such cases are
conceivable, too.I am kind of worried by the Python dependency of argparse, and prefer a
pure R solution. Would you consider merging a pull request for such a
feature, if I came up with one?—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-28102061
.
The argument against non-optional options makes sense. I'd settle for expanding the semantics of the parameter positional_arguments in parse_args: Could it also accept a pair of numbers identifying the minimum and maximum number of required positional arguments?
Such a pull request should be fine if you add some appropriate unit tests
(since quit breaks testing framework none of the unit tests should call
it) and it passes R CMD check. You might also want to add the semantic for
a single integer representing the exact number of required positional
arguments. If you use a range you might want to check if specifying a
range with Inf on the right works (i.e. the zip utility takes between 1
and undetermined large amount of positional arguments).
When print_help_and_exit is FALSE (not the default) then your new
feature probably shouldn't print help and exit either but in that case
throwing an error should be fine.
On Fri, Nov 8, 2013 at 2:59 PM, Kirill Müller notifications@github.comwrote:
The argument against non-optional options makes sense. I'd settle for
expanding the semantics of the parameter positional_arguments in
parse_args: Could it also accept a pair of numbers identifying the
minimum and maximum number of required positional arguments?—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-28105243
.