mpeterv / argparse Goto Github PK

Hi mpeterv! Thanks for the great project!
Just as a minor note, invocations like os.exit(0) and os.exit(1) are not quite portable on some non-POSIX systems (sic). So... for "greater portability", one might want to use os.exit(true) and os.exit(false) respectively.

It is very useful to parse args partially, like in Python - https://docs.python.org/3/library/argparse.html#partial-parsing

Typical usecase - add additional options, depending on the value of another option.

I want to show a full help with all options, flags... Is this supported, if not is there a recommended way to do that?

Really nice lib btw :)

I'm not sure if I'm missing something in the documentation, but it seems that default values are not printed unless they are strings. I understand this may not be possible with complicated types, but with primitives such as doubles, this would be nice to have in the output of --help.

What does this mean? I'm not a lua expert and so I have no idea what this means

Some wrapper tools adopt the convention of using -- as a marker to denote that all the arguments preceding that marker are for the wrapper tool, and everything after goes verbatim to the tool being wrapped.

So for example, CMake is a wrapper to different build tools. Say for example, I am currently using CMake to drive xcodebuild.

cmake --build /path/to/my/builddir -- -arch armv7s

So the --build goes to cmake, and -arch armv7s goes to xcodebuild.

Writing my own wrapper tools, I would like to do something like that, where argparse does the normal thing which I can use for my tool.

But for the --
I would like either an (ordered) array or all the remaining arguments, or a flat string. Then I could just forward that to the tool I'm calling.

Is there something already in argparse that can do this? If not, this would be a feature request.
Thank you.

This is a feature request for the "no" prefix modifier where you can prepend 'no' to a flag, and it inverts its value.

For example, imagine a --verbose flag that enables debugging chatter. A user can explicitly use --noverbose to do the opposite action that disables the debugging chatter.

I've used this feature in a some other argument parsing libraries for other languages, so I know the feature has been in the wild. (I'm currently trying to port a Perl utility that uses the standard GetOpt::Long which has the feature.)

I've tried emulating this with 2 flags in a mutex, but it is clumsy. The first problem is you end up with two separate flags with separate variables that still don't know that they need to be inversions of one another. So they can easily be out of sync. In the base case, where neither switch is set, then both are nil. If I set defaults to each, then when the user sets the non-default way, then both flags result in being the same value (since they don't have a direct relationship). In either case, this requires me to write extra setup code to check all the permutations and explicitly set both counterpart values in case I'm inconsistent about which variable I use to compare logic later in my app.

The second problem is you need to write two separate description entries, which can be redundant and clutter things. It seems like there should be a way to combine the entries in some ways. (The switch itself can be abbreviated as --[no]verbose.)

Thank you

Reading "the docs" of the argparse it says there is a property on every argument called choices, where you can set wich values are accepted for that argument, but that property doesn't exist

In some cases, I may want to use -h to refer to something else. It would be nice if argparse would at least detect this and disable the short form of the --help option. Alternatively, perhaps it could be possible to specify a different option to be used for the help message.

This issue derives from this Stack Overflow question. In that question, the user creates an option that takes two arguments. He can apply a convert operation, but it only applies to the option; it isn't argument-specific. So he can't convert two arguments in different ways.

The workaround provided by the answer is to use a hidden index and a sequence of functions to allow the single function to behave differently for different arguments. But it only works "by accident"; that is, it only works so long as argparse converts arguments in-order and only once per argument.

It might be better to have a more robust solution to this problem. Perhaps convert could take multiple functions, and if you provide such, it applies them to the arguments in-order.

Hi, I love that you've added argparse.version in v0.6.0, just a very trivial comment, I think the "Lua way" to do this is argparse._VERSION.

Feel free to reject this defect if I'm off-base.

Thanks

Jeff

I'd love it if argparse could generate completion files for shells (bash and zsh).

I don't see any mention of this in the docs, but it would be nice to mimic the choices parameter as seen in the python argparse module (https://docs.python.org/dev/library/argparse.html#choices).

I was going by the documentation and wanted to restrict a certain argument to only a few choices as described.

However it appears that there's no "choices" whatsoever in argparse.lua? CTRL+F for choices choice - 0 matches.

This leaves me no choice but to forget about this feature.

argparse = require("lib.argparse")

local parser = argparse("name", "descr", "footer")
parser:argument("-s --site")
	:choices{"auto","two","three"}
	:description("Type of link")

L4: attempt to call a nil value (method 'choices')

What happened there with the doc/lib?

If you define a hierarchy of command it should be organized the same way in the result table.
It would avoid name collision between command names and argument names of subcommands.

local parser = argparse()
    :name "test"

local mainCommand = parser:command "command"
local subcommand = mainCommand:command "subcommand"
subcommand:argument "arg"

lua cmd.lua command subcommand argument

{
    mainCommand = {
        subcommand = {
             arg = "argument"
        }
    }
}

I am unable to stop handling option parsing after some argument. This is useful for creating scripts that need to pass arguments when invoking shell commands. For example this sample code does not work as intended:

local argparser = require'argparse'()
argparser:flag('-s --something', "Something flag")
argparser:argument("input", "Input"):action(function()
  argparser:handle_options(false)
end)
argparser:argument("args"):args("*"):action('concat')
local options = argparser:parse()
print(table.concat(options.args, ' '))

When running with lua test.lua -s file a1 a2 -c:

Usage: playground/playground.lua [-s] [-h] <input> [<args>] ...

Error: unknown option '-c'
Did you mean one of these: '-h' '-s'?

What I would expect is when input is consumed the argparser:handle_options(false) would cancel argparser to handle options and the above example would outputs a1 a2 -c.

As far as I can see there is a mutually exclusive functionality but not a mutually inclusive functionality.
I guess it is not so hard to check if more then one value has been set or none are set.
But I think it would be really nice if the library has this future.

I know this is a bit on the opinion side but it would be nice to have linebreaks between the options for easier readability. I'd also change the way long options are listed
from:

-o <output>, --output <output>
                         Output file.

to:

--output <output>,
      -o <output>
                     Output file.

That is: stack multiple long options above each other, left pad them, and reduce the margin to allow for longer and more readable descriptions.

This might sound strange. But instead of lua script.lua --options, I am doing love . --options as I am using the LOVE engine.

Currently argparse expects me to add a parser:argument to account for the . folder, which is fine. But the help message isn't really what we want:

Usage: love [-d] [-h] <folder/>

love itself takes parameter so love -d . won't do much good.

I think a better option would be to enable argument parsing offset, ignore the . as it's handled by LOVE. I know this is rather an edge case, so it's up to your decision.

ref: https://love2d.org/wiki/Getting_Started

$> luarocks list
argparse
   0.3.1-1 (installed) - /usr/local/lib/luarocks/rocks

Old link is dead.

However, official website from readthedocs does not has a page for v0.3.1.

In the context in which I'm using argparse, it would be helpful if I could set an option to not exit when using --help or when the parsing fails.

Kinda like how Python runs stuff, I would like to be able to do fusion [ --package <package> | file ] so that either you can run fusion --package <package> or fusion <file>.

related to #7, if you are using a game engine for lua instead of pure lua, it's likely the proper shutdown isn't os.exit, in those cases, it might be better to let end-user handle the shutdown.

Returning nil instead of exiting on parser:parse() would be a solution.

ref: https://love2d.org/wiki/love.event.quit