I have a python script that I want to use as a wrapper for another commandline tool. I want to intercept any subcommands that I have defined, but pass through all other subcommands and arguments. I have tried using a subparser, which seems ideal, but it doesn't seem to allow accepting a generic undefined command, something similar to what parse_known_args does for a regular ArgumentParser.
What I currently have:
ap = argparse.ArgumentParser()
subparsers = ap.add_subparsers(
title="My Subparser",
)
upload_parser = subparsers.add_parser('upload', help='upload help')
upload_parser.add_argument(
'path',
help="Path to file for upload"
)
upload_parser.add_argument(
'--recursive',
'-r',
action='store_true',
)
What I would like to add:
generic_parser = subparser.add_parser('*', help='generic help') # "*" to indicate any other value
generic_parser.add_argument(
'args',
nargs='*',
help='generic command arguments for passthru'
)
This does not work, as it simply expects either upload or a literal asterisk *.
More precisely, I want there to be a subcommand, I just don't know before hand what all the subcommands will be (or really I don't want to list out every subcommand of the tool I'm trying to wrap).
Upon further thought I have realized that this approach is somewhat flawed for my use in a few ways, though I think that this functionality might have its uses elsewhere, so I will leave the question up.
For my case, there is a conflict between seeing the help for my tool versus the one it wraps. That is, I can't distinguish between when the user wants to see the help for the wrapper or see the help for the tool it wraps.
I think you can try Click, this is really powerful and easy to use!
just check this example
import click
#click.command()
#click.option('--count', default=1, help='Number of greetings.')
#click.option('--name', prompt='Your name',
help='The person to greet.')
def hello(count, name):
"""Simple program that greets NAME for a total of COUNT times."""
for x in range(count):
click.echo('Hello %s!' % name)
if __name__ == '__main__':
hello()
Related
I have the following code:
import argparse
parser = argparse.ArgumentParser(description='Dedupe library.', allow_abbrev=True)
parser.add_argument( '-a', '--all', nargs='+', type=int, help='(Optional) Enter one or more IDs.')
Is it possible to automatically add in the -a option when it's not specified? For example, something like:
parser.add_argument('--all', nargs='+', type=int, help='(Optional) Enter one or more IDs.')
And it can be called with:
$ parse.py -a 2
$ parse.py --all 2
Or is that not an option with argparse?
A clean way to do something like this, is by subclassing ArgumentParser and creating your own:
import argparse
class MyArgumentParser(argparse.ArgumentParser):
def add_argument(self, *args, **kwargs):
# check if one was already passed, for backward compatibility
if not any(len(a) == 2 and a.startswith('-') for a in args):
for a in args:
if a.startswith('--'):
# you could do something more fancy here, like calling an (optional) callback
return super().add_argument(a[1:3], *args, **kwargs)
return super().add_argument(*args, **kwargs)
parser = MyArgumentParser(description='Dedupe library.', allow_abbrev=True)
parser.add_argument('--all', nargs='+', type=int, help='(Optional) Enter one or more IDs.', dest='all')
Mind you, it's not necessarily a good idea. You can have conflicting options (like multiple that start with the same letter, so you might need to add code for that). And then you may have a preference for which option takes which letter with many options. Etc.
In the end, you have to ask yourself if the "convenience" offered by a solution like this really outweighs the effort of writing it, the overhead of the extra code and the lack of clarity in the resulting code for future you and other contributors that wonder where the extra options are coming from. Not to mention that it's perhaps just a good thing to explicitly state what options you're setting up?
Just that something can be done, doesn't mean you should do it.
I have created a pastebin terminal client in python. It can take some command line arguments, like -o to open a file, -n to set a paste name etc. It also has option -l which lists the pastes and allows you to delete or view pastes. The problem is that I don't know how to do it in a nice way (using argparse) - it should not allow to use -l with any other options.
I added a simple logic:
if args.name:
if args.list:
print('The -l should be used alone. Check "pb -h" for help.')
sys.exit()
Can it be done using just argparse?
I know about mutually exclusive groups, I even have one (to set paste privacy) but I haven't figured this one yet.
Full code is available here: https://github.com/lkorba/pbstc/blob/master/pb
I don't think you can use argparse to achieve your goal in "a nice way" as you say.
I see 2 options here:
1) The simpler solution as I get it would be to just check your arguments after parsing them. Nothing fancy just:
args = parser.parse_args()
if args.list is not None:
if not (args.name is None and args.open is None and
args.public is None and args.format is None and args.exp is None):
parser.error('Cannot use list with name, open, public, format or exp argument')
2) On the other hand you could revise a bit your program and use
subparsers like:
subparsers = parser.add_subparsers(title="commands", dest="command")
parser_a = subparsers.add_parser('list', help='list help')
parser_b = subparsers.add_parser('action', help='Any action here')
parser_b.add_argument('-f', action="store", help='Choose paste format/syntax: text=None, '
'mysql=MYSQL, perl=Perl, python=Python etc...')
parser_b.add_argument('-n', '--name', action="store")
parser_b.add_argument('-o', '--open', action="store", help='Open file')
...
args = parser.parse_args()
if args.command == 'list':
...
elif args.command == 'action':
...
So, for example if you pass list -n='Name' as arguments in the latter case you will get an error:
usage: subparser_example.py [-h] {list,action} ...
subparser_example.py: error: unrecognized arguments: -n='Name'
Of course you also get (as overhead) one extra parameter action here...
I have a script that finds test names and is widely used in our company. It operates on the command line like so:
find_test.py --type <type> --name <testname>
Inside the script is the equivalent of:
import argparse
parser = argparse.ArgumentParser(description='Get Test Path')
parser.add_argument('--type', dest='TYPE', type=str, default=None, help="TYPE [REQUIRED]")
parser.add_argument('--name', dest='test_name', type=str, default=None, help="Test Name (Slow)")
parser.add_argument('--id', dest='test_id', type=str, default=None, help="Test ID (Fast)")
parser.add_argument('--normalise', dest='normalise', action="store_true", default=False, help="Replace '/' with '.' in Test Name")
args = parser.parse_args()
(Not sure what all these arguments do, I personally only use the first two). These lines are then proceeded by the code that uses these arguments.
I want to refactor this script so I can import it as a module, but also preserve its command line functionality - since lots of people use this script and it is also called in some of our csh scripts.
I have refactored it so far, like so:
def _main():
<all the former code that was in find_test.py>
if __name__ == "__main__":
_main()
And this still runs fine from the command line. But I don't know how then in my parent script I pass arguments with the relevant switches into this.
How do I refactor this further and then call it in parent script?
Is this possible?
I'd also rather not use docopts which i've read is the new argparse unless necessary - i.e. can't be done with argparse, since it's not installed company wide and this can be an arduous procedure.
You shouldn't just move all the code directly into a function; that doesn't help at all.
What you should do is move the code that needs to run whatever happens into a function. (And since it is the external interface, it should not begin with _.) The code that only needs to run from the command line - ie the parser stuff - should stay in the __name__ == '__main__' block, and it should pass its results to main().
So:
def main(TYPE, test_name, test_id=None, normalise=False):
# ... body of script...
if __name__ == "__main__":
parser = ...
...
args = parser.parse_args()
main(**vars(args))
(And docopt isn't the new anything; it's an external library which some people like.)
So I have the following code:
parser = argparse.ArgumentParser(description='Manages anime_list.json', add_help=True, version='0.1')
parser.add_argument('-l', '--list', action='store_true', help='List all anime in file')
subparser = parser.add_subparsers(title='Actions', description='Actions that can be performed', dest='command')
add = subparser.add_parser('=add', help='Add anime entry')
add.add_argument('-n', '--name', type=str, required=False, default='',
help='The name of the anime adding. Will be auto filled in if left blank')
add.add_argument('-e', '--episode', type=int, required=False, default=0,
help='The last watched episode. Download starts add +1 this episode')
add.add_argument('-u', '--url', type=str, required=True, help='A link to any episode for the anime')
remove = subparser.add_parser('=remove', help='Remove anime entry')
remove.add_argument('-n', '--name', type=str, required=True, default='',
help='The name of the anime to remove')
args = parser.parse_args()
What I want is for the subparsers to be optional. When the user uses the --list argument, the subparsers arguments should not have to be supplied. When using argsparse's -h or -v options the parsing completes and the help information or version number is shown. But when just using my own -l it throws an exception saying that not enough arguments have been supplied.
I found a suggestion saying that using subparser.required = False should make them optional but it does not work.
Any idea how I can do this? I have looked up on this and can't seem to find a solution.
So I have found a solution, it's not optimal in my opinion but it works.
Thanks to Matthew in this answer.
Modifying the code like follows give me the functionality I want.
parser = argparse.ArgumentParser(description='Manages anime_list.json', add_help=True, version='0.1')
parser.add_argument('-l', '--list', action='store_true', help='List all anime in file')
args, sub_commands = parser.parse_known_args()
if args.list:
print 'Doing list'
else:
subparser = parser.add_subparsers(title='Actions', description='Actions that can be performed', dest='command')
add = subparser.add_parser('=add', help='Add anime entry')
add.add_argument('-n', '--name', type=str, required=False, default='',
help='The name of the anime adding. Will be auto filled in if left blank')
add.add_argument('-e', '--episode', type=int, required=False, default=0,
help='The last watched episode. Download starts add +1 this episode')
add.add_argument('-u', '--url', type=str, required=True, help='A link to any episode for the anime')
remove = subparser.add_parser('=remove', help='Remove anime entry')
remove.add_argument('-n', '--name', type=str, required=True, default='',
help='The name of the anime to remove')
args = parser.parse_args()
print args
return args
Basically parse the known arguments, in this case it would be the -l one. If the -l argument was not supplied, add the required subparsers and parse the arguments again.
If it is done this way, your --help will not work anymore as it will not show the subparsers' help text. You will have to create a manual help function.
Throw in a default parameter. For example:
parser.add_argument('-l', '--list', action='store_true', help='List all anime in file', default=False)
This will store a default value of False, and only when the -l flag is provided will the list variable be True.
I use the following solution, I find it quite clean, and it helps me to extend and make more specific my command line applications.
1) Define a main common and standard argparse with parent and subparsers. I do this in the main library or in a common class that I use in similar but different projects.
2) Add a subparser to escape the common argparse, something like "other" or something similar.
3) In the specific applications create a second argparser that is used when the first argument is "other".
example:
let's say I want to always use/inherit some common subparsers and parent but then also add some application specific parsers. Say the standard common parser has the following subparsers: load, query, show, ..., other.
then it will work with:
python code.py load -arg1 -arg2 ...
python code.py show -arga -argb ...
while, when using "other" it will take the parent args and do nothing, so that other case specific parsers can be used.
python code.py other application_specific_command -arg3 -arg4
clearly this does not make the subparser optional, so it is not a direct answer; more a possible alternative that works in some cases. I think it offers some advantages:
1) logic implementation without many if or try 2) can pass the parent args to the application specific parser (if "other" has parents) 3) allows some common args for "other", i.e. for all the case specific commands 4) maintains args helps
I have a program that uses a default name and password. I'm using argparse to allow the user to specify command line options, and I would like to enable the user to provide the program with a different name and password to use. So I have the following:
parser.add_argument(
'-n',
'--name',
help='the login name that you wish the program to use'
)
parser.add_argument(
'-p',
'--password',
help='the password to log in with.'
)
But it doesn't make any sense to specify only the name or only the password, but it would make sense to specify neither one. I noticed that argparse does have the ability to specify that two arguments are mutually exclusive. But what I have are two arguments that must appear together. How do I get this behavior? (I found "argument groups" mentioned in the docs, but they don't appear to solve my problem http://docs.python.org/2/library/argparse.html#argument-groups)
I believe that the best way to handle this is to post-process the returned namespace. The reason that argparse doesn't support this is because it parses arguments 1 at a time. It's easy for argparse to check to see if something was already parsed (which is why mutually-exclusive arguments work), but it isn't easy to see if something will be parsed in the future.
A simple:
parser.add_argument('-n','--name',...,default=None)
parser.add_argument('-p','--password',...,default=None)
ns = parser.parse_args()
if len([x for x in (ns.name,ns.password) if x is not None]) == 1:
parser.error('--name and --password must be given together')
name = ns.name if ns.name is not None else "default_name"
password = ns.password if ns.password is not None else "default_password"
seems like it would suffice.
I know this is more than two years late, but I found a nice and concise way to do it:
if bool(ns.username) ^ bool(ns.password):
parser.error('--username and --password must be given together')
^ is the XOR operator in Python. To require both arguments given at the command line is essentially an XOR test.
This is probably how I'd do it. Since you have existing defaults with the option to change, define the defaults, but don't use them as your argument defaults:
default_name = "x"
default_pass = "y"
parser.add_argument(
'-n',
'--name',
default=None,
help='the login name that you wish the program to use'
)
parser.add_argument(
'-p',
'--password',
default=None,
help='the password to log in with.'
)
args = parser.parse_args()
if all(i is not None for i in [args.name, args.password]):
name = args.name
passwd = args.password
elif any(i is not None for i in [args.name, args.password]):
parser.error("Both Name and Password are Required!")
else:
name = default_name
passwd = default_pass