The docs for the (awesome) Click package suggest a few reasons to use entry points instead of scripts, including

1. cross-platform compatibility and
2. avoiding having the interpreter assign __name__ to __main__, which could cause code to be imported twice (if another module imports your script)

Click is a nice way to implement functions for use as entry_points, btw.

How can I use entry_points to generate a binary that calls python -m mypackage (and passes *args, **kwargs) ?

I think this is the wrong way to look at the problem. You don't want your script to call python -m mypackage, but you want the script to have the same entry point as python -m mypackage

Consider this simple example:

script_proj/
├── script_proj
│   ├── __init__.py
│   └── __main__.py
└── setup.py

and the minimalistic setup.py:

from setuptools import setup

setup(
    name="script_proj",
    packages=["script_proj"],
    entry_points = {
        "console_scripts": [
            "myscript = script_proj.__main__:main",
        ]
    }
)

__main__.py is a dummy module and contains the main method.

def main():
    print("Hello world!")

if __name__ == "__main__":
    main()

After installing, you have the executable myscript, which calls the main method in __main__.py. In this package design python -m script_proj also calls the same main method.

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.

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.