Required Flags about args HOT 11 CLOSED

I thought about it a bit more and realised my needs are even more simple than I indicated. 99% of my tools work in the same way - I have a bunch of positional arguments (usually filenames), all of which are required, and some flags which are optional. Hence I only have one "required" group and one "optional" group. So if I could specify a single custom error message that would be great for me - so the user gets a "You didn't specify all the filenames" message instead of the more vague "Group validation failed somewhere!".

So just being able to replace the group validation message would work for me. Is that simpler?

(PS Thanks for the library - I have been trying to roll-my-own for years and yours is better than anything I managed)

from args.

The whole point of required arguments is not having to write extra code to handle them. With groups you still have to check which of them failed, print a custom error message and fix the help output. This actually adds an extra line and removes none. Using groups the regular way seems to have the same problem of not saving any lines of code.

from args.

Using a group works. Leave the help message of the group blank will make it not appear in the output. This is not documented and really probably should be. I'll get this part noted in the Group doxygen output.

from args.

Yes, it works, but the error message is:

 $ ./app -t 999
Group validation failed somewhere!

It didn't tell me that I'm missing -i <foo>.

That's why maybe using the groups isn't the best way to deal with required flags. Unless you can special case groups with only one item or no help message.

It would also be nice if the help message could indicate it's a required flag.

Thanks for taking the time to write this!

from args.

Ah yes, I opted for flexibility over that. Otherwise I'd have to either ditch full group validation, or handle base-level required flags separately from group validation, as the parser itself is a group, and it validates its sub groups with yet another group validator (which is the args::Group::Validators::AllChildGroups, which means that it ignores children for validations except children which are groups). In this case, you'd have to check your required groups and possibly flags individually to see where the user went wrong.

The basic gist of it, is that in order to let the program determine which flags went wrong, I'd have to put restrictions on the use of groups that I don't want to put on the users of the library, or I'd have to handle different kinds of validation in parallel, which is messier and more bug-prone.

If I knew a reasonable way to do it without those compromises, I'd be more than glad to, but I don't see one, unfortunately.

from args.

The other issue with not having a flag know it's required or not is that the generated help is wrong. For example:

$ ./app -h
  ./app {OPTIONS} [PATH...]

    This is a test program.

  OPTIONS:

      -h, --help                        Display this help menu
      -i[PATH], --inPath=[PATH]         Input path
      -v, --verbose                     Set the verbosity level
      PATH...                           Output paths

The [PATH...] means that PATH... is optional, but in reality, it's required because it's in a group.

The flexibility of using groups is great - assuming the user experience can get nailed down. Right now, that flexibility leads to 1) Poor error messages and 2) not valid help output.

Anyway, I'm not meaning to beat a dead horse. You're aware of these issues. Please feel free to close this issue.

Thanks again for the lib :)

from args.

+1 to this issue. I appreciate the power of groups, but they aren't valuable enough to come at the expense of such fundamental functionality.

I really think you should figure out a way to handle base-level required flags. Without that, the library is much less attractive and as you know, less compatible with the functionality of Python's argparse (which was initially quite an attention grabber for me).

from args.

Hm. I might have to think of a way to allow them to work as a special instance of normal group validation.

from args.

You're right. It's not going to be simple to support them in this way without a rewrite, though, which may be necessary. I'd like to enable better use of C++11 and make it more closely resemble the Python argparse anyway.

from args.

Hello. I would be happy if I could specify an error message for each group that would be printed when it fails validation.

from args.

That's not easy to support, given the way that validation works. I could work it in as only working on the base-level group, but that's about the best it could do, given that nesting groups works based on arbitrarily complex validation. I'm probably going to opt for a rewrite of the whole library at some point anyway. Something with better automatic messages and a better interface.

from args.