Code Monkey home page Code Monkey logo

yaargh's Introduction

Yaargh: Yet Another Argh

Yaargh is a fork of Argh (https://github.com/neithere/argh/).

Why fork?

The argh project is no longer maintained (neithere#124 (comment)). This project will attempt to fix issues and make improvements to the original project. The intent is for all these changes to be made back to the original argh project when that becomes possible, and for yaargh to act as a replacement until it is.

You can use yaargh as a drop-in replacement for argh (import yaargh as argh) though see Compatability below.

In order to support using yaargh automatically even in applications where you can't easily change the code, the optional feature yaargh[import-argh] will add a dummy argh module such that import argh will use yaargh.

Highlights

The most signifigant differences from argh, and reasons you may prefer to use it:

  • Commands that fail with a CommandError now exit with status 1 (failure) instead of status 0 (success). This is extremely important when used in scripts.

Compatability

While yaargh strives to maintain backwards compatability with argh and its existing behavior, the nature of a library like argh with a large amount of "magic" behavior and defaults means that what we consider the best default may change from version to version. For example, help text wording may change.

In addition, there is behavior that is almost always a bug but that it is technically possible some users rely on.

Both kinds of compatability breaks are listed below:

  • If a function's type signature included a *varargs argument with an annotation of type str, this annotation previously was ignored. Now, that annotation will be used as a help string. In almost all cases this should be fixing behavior to match user intent, but it will technically result in different --help output.
  • Previously, if a function raised a yaargh.CommandError or an error explicitly marked as wrapped, then yaargh.dispatch() (and by extension yaargh.dispatch_command() and yaargh.dispatch_commands()) would write the error message to the given error_file (by default sys.stderr), then return. It now raises a SystemExit instead of returning. In almost all cases, dispatch() is the last thing the program does anyway, and parsing failures already caused a SystemExit to be raised so most users who need to do something after error will already be catching it. This is a signifigant break but is nessecary to allow non-zero exit codes for failed commands.
  • Related to the above, commands that fail with a yaargh.CommandError or other wrapped error will now exit with status 1, indicating failure. Previously, unless the user did something to avoid it, the command would have returned from yaargh.dispatch() and subsequently exited success. In the vast majority of cases this would have been a latent bug likely to cause havoc in scripts or other systems which rely on status code to check if a command succeeded. You can use CommandError(message, code=0) to restore the previous behavior.

Original README

Building a command-line interface? Found yourself uttering "argh!" while struggling with the API of argparse? Don't like the complexity but need the power?

Everything should be made as simple as possible, but no simpler.

—Albert Einstein (probably)

Argh is a smart wrapper for argparse. Argparse is a very powerful tool; Argh just makes it easy to use.

In a nutshell

Argh-powered applications are simple but flexible:

Modular:

Declaration of commands can be decoupled from assembling and dispatching;

Pythonic:

Commands are declared naturally, no complex API calls in most cases;

Reusable:

Commands are plain functions, can be used directly outside of CLI context;

Layered:

The complexity of code raises with requirements;

Transparent:

The full power of argparse is available whenever needed;

Namespaced:

Nested commands are a piece of cake, no messing with subparsers (though they are of course used under the hood);

Term-Friendly:

Command output is processed with respect to stream encoding;

Unobtrusive:

Argh can dispatch a subset of pure-argparse code, and pure-argparse code can update and dispatch a parser assembled with Argh;

DRY:

The amount of boilerplate code is minimal; among other things, Argh will:

  • infer command name from function name;
  • infer arguments from function signature;
  • infer argument type from the default value;
  • infer argument action from the default value (for booleans);
  • add an alias root command help for the --help argument.
NIH free:

Argh supports completion, progress bars and everything else by being friendly to excellent 3rd-party libraries. No need to reinvent the wheel.

Sounds good? Check the tutorial!

Relation to argparse

Argh is fully compatible with argparse. You can mix Argh-agnostic and Argh-aware code. Just keep in mind that the dispatcher does some extra work that a custom dispatcher may not do.

Installation

Using pip:

$ pip install argh

Arch Linux (AUR):

$ yaourt python-argh

Examples

A very simple application with one command:

import argh

def main():
    return 'Hello world'

argh.dispatch_command(main)

Run it:

$ ./app.py
Hello world

A potentially modular application with multiple commands:

import argh

# declaring:

def echo(text):
    "Returns given word as is."
    return text

def greet(name, greeting='Hello'):
    "Greets the user with given name. The greeting is customizable."
    return greeting + ', ' + name

# assembling:

parser = argh.ArghParser()
parser.add_commands([echo, greet])

# dispatching:

if __name__ == '__main__':
    parser.dispatch()

Of course it works:

$ ./app.py greet Andy
Hello, Andy

$ ./app.py greet Andy -g Arrrgh
Arrrgh, Andy

Here's the auto-generated help for this application (note how the docstrings are reused):

$ ./app.py help

usage: app.py {echo,greet} ...

positional arguments:
    echo        Returns given word as is.
    greet       Greets the user with given name. The greeting is customizable.

...and for a specific command (an ordinary function signature is converted to CLI arguments):

$ ./app.py help greet

usage: app.py greet [-g GREETING] name

Greets the user with given name. The greeting is customizable.

positional arguments:
  name

optional arguments:
  -g GREETING, --greeting GREETING   'Hello'

(The help messages have been simplified a bit for brevity.)

Argh easily maps plain Python functions to CLI. Sometimes this is not enough; in these cases the powerful API of argparse is also available:

@arg('text', default='hello world', nargs='+', help='The message')
def echo(text):
    print text

The approaches can be safely combined even up to this level:

# adding help to `foo` which is in the function signature:
@arg('foo', help='blah')
# these are not in the signature so they go to **kwargs:
@arg('baz')
@arg('-q', '--quux')
# the function itself:
def cmd(foo, bar=1, *args, **kwargs):
    yield foo
    yield bar
    yield ', '.join(args)
    yield kwargs['baz']
    yield kwargs['quux']

Links

Author

Developed by Andrey Mikhaylenko since 2010.

See file AUTHORS for a complete list of contributors to this library.

Support

The fastest way to improve this project is to submit tested and documented patches or detailed bug reports.

Otherwise you can "flattr" me: Flattr the Argh project

Licensing

Argh is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

Argh is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with Argh. If not, see <http://gnu.org/licenses/>.

yaargh's People

Contributors

neithere avatar ekimekim avatar tanriol avatar felixonmars avatar joequery avatar melor avatar coolcold avatar dwf avatar madjar avatar jwilk avatar hzpc-joostk avatar mnencia avatar floppym avatar saaros avatar tony avatar invl avatar jakirkham avatar mafrosis avatar

Stargazers

Sebastian Weigand avatar Muhammad N ElNokrashy avatar nraw avatar  avatar

Watchers

James Cloos avatar  avatar

Forkers

presheaf

yaargh's Issues

Handle foo=True args in saner way

Right now the behaviour is for foo=True to create a --foo arg with store_false, ie. so that --foo means foo=False. This is very counterintuitive.

neithere#73 has some thoughts on this, and I've implemented a similar thing in my own usage previously as an explicit custom Action that adds --foo and --no-foo args.

Open questions:

  • Do we want both --foo and --no-foo, or do we just want --no-foo if the default is foo=True
  • There should still be a way to opt into both --foo and --no-foo, especially if the default is dynamic based on other conditions - the one that comes up a lot personally is something like --color --no-color with default being sys.stdout.isatty().
  • How do we reconcile this with existing behaviour without breaking backwards compatability too badly?
  • Does it make sense to combine this with short args? eg. -f=true/false or -f=yes/no (probably not - if the user wants this they can explicitly use choices=["yes","no"])

Use of @arg(dest=...) doesn't change required function signature

It would be really nice if this kind of construct worked:

@argh.arg("--bar", action="store_const", const="bar", dest="foo")
@argh.arg("--quux", action="store_const", const="quux", dest="foo")
def main(foo="baz"):
  print(foo)
usage: example.py [-h] [--bar] [--quux]
$ example.py
baz
$ example.py --bar
bar
$ example.py --quux
quux

This is a bit of a major change since each function arg no longer directly maps to an argument. It's also unclear how this would work in combination with other edge cases, or how to properly set the default value (baz in this example). It's also not a super important use case, since --foo=(bar|baz|quux) is in many cases more natural and is easy to do with choices=.... It's also unclear what the result would be in the case of eg. example.py --bar --quux (would it brint bar or quux?).

This issue is unlikely to be implemented, it's just here to organize my thoughts.

Issues around underscores, dashes and metavars

Currently, argh has some somewhat inconsistent behaviour with respect to how arguments are presented based on their name:

Arg Type Name Metavar Usage
foo_bar Positional foo_bar foo_bar example.py foo_bar
_foo_bar Positional _foo_bar _foo_bar example.py _foo_bar
foo_bar=default Option --foo-bar FOO_BAR example.py [--foo-bar FOO_BAR]
_foo_bar=default Option ---foo-bar N/A Crashes during assembly
*foo_bar Multiple Positional foo_bar foo_bar example.py [foo_bar [foo_bar ...]]
*_foo_bar Multiple Positional _foo_bar _foo_bar example.py [_foo_bar [_foo_bar ...]]

Note that positional args are lowercased with underscores, whereas options are replaced with dashes (for name) or uppercased (for metavar).

Note also that leading underscores are treated naively, which leads to a bug for options.

We cannot safely change the behaviour of names, as this will break compatability in a serious way (people's @arg decorators will no longer match the right args), but this is fine since it's not name that matters to the usage string for positional args.

See also discussion from upstream: neithere#79, neithere#106

I pretty strongly believe that lowercased metavars for positional args is a mistake. In most usage conventions, lowercase strings are intended to be taken as literals and uppercase as variables, eg. from ip link help: Usage: ip link add [link DEV] [ name ] NAME. This also clears up the consistency of dashes vs underscores, since positional arg metavars will now act the same as option metavars, ie. FOO_BAR.

The other option to resolve the inconsistency would be to set the metavar as foo-bar, and this is the solution suggested in neithere#106. But I would rather have positional metavars match option metavars rather than option names.

Then there is the question of underscore-prefixed args.
By python conventions this would denote an "internal use only" argument.
This seems like a reasonable convention for us to adopt, where underscore-prefixed arguments with defaults are simply ignored when assembling, as we assume they're for use internally within the application.
This also works for *_args - we can assume the extra args are to be passed only in internal calls, though this would be a backwards-incompatible change.
However, this doesn't map cleanly to single arguments without defaults - we need to give some value for these args.

I see three options:

  • Keep the current behaviour of treating these args no differently to ones without underscores
  • Pass None for these args
  • Raise an error for this case during assembly

I am leaning towards option 2, but I could see any of these options as being fairly sane behaviour here (especially since the user could trivially add a =None if option 2 is what they actually want).
If we go with option 1, it is a strong argument for also keeping the current behaviour for *_args for consistency.

So then, assuming option 1 above, this would be our new behaviour:

Arg Type Name Metavar Usage
foo_bar Positional foo_bar FOO_BAR example.py FOO_BAR
_foo_bar Positional _foo_bar _FOO_BAR example.py _FOO_BAR
foo_bar=default Option --foo-bar FOO_BAR example.py [--foo-bar FOO_BAR]
_foo_bar=default Internal N/A N/A Ignored, always called with default
*foo_bar Multiple Positional foo_bar FOO_BAR example.py [FOO_BAR [FOO_BAR ...]]
*_foo_bar Multiple Positional _foo_bar _FOO_BAR example.py [_FOO_BAR [_FOO_BAR ...]]

One very nice thing about these choices is that the only backwards-incompatible changes are to the exact syntax of the usage (which no-one should be programatically relying on), plus behaviour that used to be an error.

When using namespaces, omitting subcommand doesn't print correct usage

When multiple commands are available but you call your program with no arguments (and no default command is set), it prints basic usage.

However, when you have a namespace with multiple commands (eg. git svn init, git svn fetch) and you call it with the namespace but no commands (git svn), it still prints the basic usage of the top-level commands, NOT the basic usage for that namespace.

Fixing this will probably involve changing the subsubparser construction in assembling.add_commands so that we get some indicator in the namespace if the subparser is reached but then nothing matches within it. Then where we currently do parser.format_usage() we should discover the "last reached parser" and format usage for THAT parser instead.

Feature: Exception for user to raise that prints usage

While argparse is a wonderful thing, there's often complex constraints on argument validity that it cannot fully encode. For example, mutually exclusive options (--foo cannot be used with --bar).

In these cases, the user generally checks these constraints near the start of their command function. However, if the constraints fail then the user is left with a dilemma. Their choices are:

  • Raise a generic Exception: This is a bad experience for the caller, as now they're confronted with a traceback and an apparent program error, when what the program is actually trying to tell them is that they called it wrong.
  • Directly print an error message and exit: This is better but still not ideal. They can tell the caller what they did wrong, but this is inconsistent with most other kinds of "you called it wrong" errors, where the error message also includes the usage:
$ python example.py --foo=a
usage: example.py [-h] [-f FOO]
example.py: error: argument -f/--foo: invalid int value: 'a'
  • Raise a CommandError: This is about the same as directly printing an error.

What we want is the ability for the user to cause an error with usage to be printed, similar to if a required arg were not given or a value failed to be parsed.

So we should add an yaargh.exceptions.UsageError. Like a CommandError this is intended to be raised by users, but unlike a CommandError it will cause usage information to be printed along with the error message.

Support

Hi @ekimekim

Thank you for continuing the development of argh. As I use argh very often in my scripts, I would like to help you.

I had the following idea neithere#137

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.