-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement API for "subcommand" style interfaces #43
Comments
nice idea! |
After thinking about it, I'm not sure my suggested method for how to implement this is the best one (though it might work fine, it depends on plumbum internals, which I'm not that familiar with), but regardless, I'd like to see some kind of subcommand support in plumbum. Thanks for giving the world such a nice tool! |
here's a sketch: class Git(cli.Application):
@cli.subcommand("commit")
class Commit(cli.Subcommand):
@cli.switch("-a")
def all(self):
pass
@cli.switch("-m", str)
def message(self, msg):
pass which allows you to write run |
Ah, nice! And you could maybe still use |
Though it would also be nice to have a way to define subcommands outside of the Also an API for adding subcommands to a
or something like that. This would allow you to store your subcommands someplace else and import them. Useful for anyone who wants to build a plugin architecture around this. |
a better approach: class GitCommit(cli.SubApplication):
@switch("-a")
def all(self):
pass
class Git(cli.Application):
commit = cli.Subcommand(GitCommit)
verbose = cli.Flag("--verbose") |
Yes, that's even nicer. As long as whatever processes/detects the subcommands happens when questions:
It seems to me that you might only need either a special type for subcommands ( Hmmm...maybe you need both in order to give the subcommand a reference to the parent application? (You might need this in order to e.g. honor a global |
Totally awesome! Way to go! |
Plumbum should provide an API for "subcommand" style interfaces, in which the cli app has a number of subcommands.
e.g. svn, hg, bzr, git, etc.
One way to do this might be to provide a
cli.subcommand
decorator which you would use to decorate functions in acli.Application
. Then the parsing logic would look for any of these and use whichever one was specified on the command line instead of the currentmain
method.The text was updated successfully, but these errors were encountered: