We Keep Coding

Is it possible to embed an argsparse parser in a function?

I define an argsparse object like this:
parser = argparse.ArgumentParser(description='{desc}', formatter_class=argparse.ArgumentDefaultsHelpFormatter)\
.format(desc=description)
Then I add arguments like this:
parser.add_argument("--config", "-c", help='config',
default='dbConf').format(dbConf=dbConfig)
Since I use these two lines in many scripts, I want to embed them into a function.
However, to my understanding the parser.add_argument() listens to the command line.
Is it possible to embed these lines into a function?

Is it possible to embed these lines into a function?
Yes. add_argument doesn't interact with the command line at all, though even if it did that would make little difference.
The one bit of argparse which interacts with the CLI input is the parse_args method, and what it does by default is access the global sys.argv attribute and process it. I wrote by default because you can also provide a list of strings as first parameter and it'll process that instead (if you click the link you'll see the official documentation does that to demonstrate various things in the examples).
So yes, you can very much have a function which creates an ArgumentParser and starts configuring it, then returns it for more configuration and ultimately, well, parsing the arguments.

How can a Py script call a "setup/configure" function only on first-run?

I've been learning Python and decided to make a note-taking utility that runs in bash. I've worked out the basic 'guts' and I want to add a feature that allows a new user to configure their notes (for instance, set the directory where new note files are stored).
I realize this means running a 'install/config' function that is only called the first time the user runs the script (or until they configure it). I don't know what this concept is called, and after some research, cannot find anything about it w/Python.
I'm using argparse. You call the python script from the shell and can optionally use it with arguments. If it would help to see my code, please let me know and I'll format it (it's long and needs to be edited a bit if I want to post). Thanks.
tl;dr How do you run a function only once in Python (either first time code is executed, or until the function's purpose - in this case, setting a file path - is fulfilled)?

Argparse combine --help directives

I am currently building an extension to an existing library that uses argparse.ArgumentParser() to ingest cli arguments, and have added my own argparse.ArgumentParser() using parse_known_args() to parse out the arguments I want to inject before passing the remaining arguments on to the existing library's implementation. I am doing this instead of adding the arguments to the underlying library so that if the underlying library changes, everything should still work.
However, when I pass in the --help flag my implementation of argparse.ArgumentParser() grabs that flag, prints out help for my injected arguments then breaks execution so it never gets to the help message for the underlying library.
I am having trouble figuring out if there's a way to combine the help directives for both argparse.ArgumentParser() implementations (if it's even possible), or how to ignore the help flag in my implementation. My added arguments are for debug only and are not vital to display to the end user of my extended library, so if there is a way to ignore the help flag in my implementation, that would be OK, while not ideal.

I think this may be an answer to your question. add_help=False, but added to subcommands and subparsers. Python argparse - disable help for subcommands?

You need to pass parents parameter to the subsequent parsers. I've just posted an answer to a similar question here:
Argparse: is it possible to combine help texts from multiple parsers?

How to construct argparse parameters for different actions

How would you construct a Python argparse parser to support different parameters organized by a top-level action, as well as have argparse's default help functionality distinguish between the different action/option groups?
e.g.
$ myprog.py list --verbose
Listing records:
...
$ myprog.py run --iterations=10
Running
...
$ myprog.py help
usage: myprog.py [action]
positional arguments:
action {list,run,help}
list Lists records.
run Process records.
help Show action help.
$ myprog.py help run
usage: myprog.py run [--iterations=N] [--verbose] [--skip]
optional arguments:
--iterations N Process N records.
--verbose Show extra messaging.
--skip Skip previously seen IDs.
I thought this might be supported by the parents feature, but this seems more designed to grouping option groups than separate argument actions.

here's an example I made of using parsers and subparsers with argparse to achieve something close to what you're looking for, and that's a code to access SO by CLI ;-)
I'd also advise you to have a look at docopt

You could parse the first item, make your choice, then have different argument parsers for each item. If you want to share some commands, then you can use the parents feature to share some arguments between your various commands.

parents is a convenient way of adding arguments to one or more parsers. It does not affect the parsing or the help.
add_argument_group is a way of grouping arguments in the help. It may be what you need. It does not, though, affect how the arguments are parsed. The default groupings are 'positional' and 'optional' (meaning 'uses a flag').
add_subparsers is a way of both grouping arguments and their parsing. With it you create new parsers that are invoked with simple commands. Each subparser has its own set of arguments (and own help display)
If you want to organize the help in an entirely different way, consider writing your own usage and description, and suppressing the default help lines with help=argparse.SUPPRESS.
IPython is an advanced user of argparse. It detects help in sys.argv before calling argparse, and thus bypasses the default help.

Should I forward arguments as *args & **kwargs?

I have a class that handles command line arguments in my program using python's optparse module. It is also inherited by several classes to create subsets of parameters. To encapsulate the option parsing mechanism I want to reveal only a function add_option to inheriting classes. What this function does is then call optparse.make_option.
Is it a good practice to simply have my add_option method say that it accepts the same arguments as optparse.make_option in the documentation, and forward the arguments as *args and **kwargs?
Should I do some parameter checking beforehand? In a way I want to avoid this to decouple that piece of code as much from a specific version of optparse.

It seems that you want your subclasses to have awareness of the command line stuff, which is often not a good idea.
You want to encapsulate the whole config input portion of your program so that you can drive it with a command line, config file, other python program, whatever.
So, I would remove any call to add_option from your subclasses.
If you want to discover what your config requirements look like at runtime, I would simply add that data to your subclasses; let each one have a member or method that can be used to figure out what kind of inputs it needs.
Then, you can have an input organizer class walk over them, pull this data out, and use it to drive a command line, config file, or what have you.
But honestly, I've never needed to do this at run time. I usually pull all that config stuff out to it's own separate thing which answers the question "What does the user need to tell the tool?", and then the subclasses go looking in the config data structure for what they need.

Are you sure that subclassing is what you want to do? Your overriding behavior could just be implemented in a function.