>What would cause that confusion? This is not something that would
>change how ‘argparse’ parses its arguments, so I don't know what
>you're referring to.

The (possible) confusion is the existence of a manpage only available though argparse (`./python foo.py --manpage`) and not systemwide. I am not sure how many people do something like `./python poc_2.py > output && man ./output` to **read** the manpage.

>This is asking that the ‘argparse’ library should have an API to
>create a manual page, for use in the build system.

At this point argparse is user facing in the sense that once configured, it provides functionality for the user of the command line application. My opinion is that it will be weird to have it provide also APIs for creating man pages (which is a developer utility). My humble opinion is that it if argparse starts to provide APIs for usage at install time is not "doing one thing and doing it well".

>The reason to have it in the ‘argparse’ library is that the library
>already knows how to build a single document (the ‘--help’ output)
>from the collection of arguments, so this would be just another
>rendering of that information. It makes sense to have it in the
>‘argparse’ library as an API for other tools to use

Argparse --help makes sense because people expect to use -h or --help with command line tools but IMHO opinion nobody expects --manpage to be the way to read the manpage. I do not know any command line utility that provides its manpage that way. If the argument is using --manpage is the way to generate one, then we are mixing user-facing options with developer ones.

Anyway, this is just my view of the problem, nothing more.