Just to give a full picture of what megazord.py would look like, using @Jeffrey Harris suggestion to use a nice library for parsing the inputs.

import argparse

def main():
    ''' Example of taking inputs for megazord bin'''
    parser = argparse.ArgumentParser(prog='my_megazord_program')
    parser.add_argument('-i', nargs='?', help='help for -i blah')
    parser.add_argument('-d', nargs='?', help='help for -d blah')
    parser.add_argument('-v', nargs='?', help='help for -v blah')
    parser.add_argument('-w', nargs='?', help='help for -w blah')

    args = parser.parse_args()

    collected_inputs = {'i': args.i,
                    'd': args.d,
                    'v': args.v,
                    'w': args.w}
    print 'got input: ', collected_inputs 

And with using it like in the above, one would get

$ megazord -i input -d database -v xx-xx -w yy-yy
got input: {'i': 'input', 'd': 'database', 'w': 'yy-yy', 'v': 'xx-xx'}

And since they are all optional arguments,

$ megazord
got input: {'i': None, 'd': None, 'w': None, 'v': None}

An "entry point" is typically a function (or other callable function-like object) that a developer or user of your Python package might want to use, though a non-callable object can be supplied as an entry point as well (as correctly pointed out in the comments!).

The most popular kind of entry point is the console_scripts entry point, which points to a function that you want made available as a command-line tool to whoever installs your package. This goes into your setup.py script like:

entry_points={
    'console_scripts': [
        'cursive = cursive.tools.cmd:cursive_command',
    ],
},

I have a package I've just deployed called cursive.tools, and I wanted it to make available a "cursive" command that someone could run from the command line, like:

$ cursive --help
usage: cursive ...

The way to do this is define a function, like maybe a cursive_command function in the file cursive/tools/cmd.py that looks like:

def cursive_command():
    args = sys.argv[1:]
    if len(args) < 1:
        print "usage: ..."

and so forth; it should assume that it's been called from the command line, parse the arguments that the user has provided, and ... well, do whatever the command is designed to do.

Install the docutils package for a great example of entry-point use: it will install something like a half-dozen useful commands for converting Python documentation to other formats.

If there is not a good reason to not do so, I would definitely advocate a spin on option 3. As @jonsharp mentions, breaking up your utility into clean units of functionality is a good way to ensure testability. Even the smallest scripts can eventually morph into a much larger program and making sure that you have an extensible API sooner rather than later will alleviate much headache down the road.

The way I'd approach this is:

1. Break up your code into logical methods with clean and clear I/O
2. Add unit tests. Having them is never a bad thing.
3. Rather than using if __name__ == '__main__', create a main() (or similar) method containing your entry point
4. Use setuptool's setup() function to define the script entry point in your setup.py file.

For example:

from setuptools import setup
setup(
    name='mypackage',
    version='0.1',
    entry_points={
        'console_scripts': [ 'myscript = mypackage.mymodule:main' ],
    }
)

Now, not only is all of your code (including main()) is easily unit testable, but you can still have your console entry point once you've done a python setup.py install|develop.

Any validation I do using, say, ArgumentParser.add_mutually_exclusive_group will not apply when my tool is run as a library instead of a command line script.

Depending on how your API is designed, you may need to add some extra validation to input parameters, but that should likely be there to prevent unexpected input anyways.

Edit: The only time I would use generally use subprocess is when I'm calling into a non-Python application or another Python script that I don't own or have the time to refactor, but the latter only being as a last resort. Most well-written Python utilities will expose both command line utilities and internal API.

According to setuptools' documentation on "Automatic Script Creation" this is not possible:

The functions you specify are called with no arguments

Alternatively you could do such a thing:

In __main__.py:

def main_true():
    return main(print_me=True)

In setup.py:

entry_points={
    'console_scripts': [
        'test = mypackage.__main__:main_true'
     ],
},

But in this particular case since True is already the default argument for the parameter print_me, this is probably not necessary, and changing 'test = mypackage.__main__:main(print_me=True)' to 'test = mypackage.__main__:main' should be enough.

The section must be [options.entry_points]. See an example at https://github.com/github/octodns/blob/4b44ab14b1f0a52f1051c67656d6e3dd6f0ba903/setup.cfg#L34

[options.entry_points]
console_scripts =
    octodns-compare = octodns.cmds.compare:main
    octodns-dump = octodns.cmds.dump:main
    octodns-report = octodns.cmds.report:main
    octodns-sync = octodns.cmds.sync:main
    octodns-validate = octodns.cmds.validate:main

Directly from the documentation on click.pocoo.org:

yourscript.py:

import click

@click.command()
def cli():
    """Example script."""
    click.echo('Hello World!')

setup.py:

from setuptools import setup

setup(
    name='yourscript',
    version='0.1',
    py_modules=['yourscript'],
    install_requires=[
        'Click',
    ],
    entry_points='''
        [console_scripts]
        yourscript=yourscript:cli
    ''',
)

While if you have multiple commands in your CLI application, I usually create a click group like this:

init.py:

import click

@click.group()
@click.option('--debug/--no-debug', default=False, help='My test option.')
def cli(debug):
    """Add some initialisation code to log accordingly for debugging purposes or no"""
    pass  

@cli.command()
def configure():
    """Configure the application"""
    pass

And the setup.py file looks exactly the same as the one in the click documentation.