Git Product home page Git Product logo

argparse's People

Contributors

alloyed avatar jsbackus avatar mpeterv avatar stepelu avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

argparse's Issues

Prettier help strings.

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.

How to stop handling options after an 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.

Argument 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?

Very trivial issue - argparse.version

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

Add ability to add arguments to a mutex

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>.

Command hierarchy should be reflected in the result table

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"
        }
    }
}

mutually inclusive functionality

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.

choices property is not recognized

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

Replace non-portable os.exit() invocations

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.

Support for trailing '--' to indicate remaining options to be captured/forwarded verbatim

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.

Allow offset for argument parsing

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

Print default values even if non string

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.

Allow changing help option argument

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.

Support 'no' prefix for negatable flags (e.g. --verbose or --noverbose)

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

Option to not exit on help or error

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.

Multi-argument options and conversion

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.