On Thu, 2018-06-14 20:02 +0000, Pablo Galindo Salgado <report@bugs.python.org> wrote:
> The (possible) confusion is the existence of a manpage only available 
> though argparse (`./python foo.py --manpage`)

This report isn't asking for that. (I see only one person proposing such an interface, and even that person said it's not a good idea.) So please don't conflate that with the original bug report.

> I am  not sure how many people do something like `./python poc_2.py > output 
> && man ./output` to **read** the manpage.

Right, I am not asking for anything like that; I'm not asking that ‘argparse’ grow a way to read a manual page,. I am asking only for a standard way to programmatically generate that manual page from the information ‘argparse’ already knows.

> >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).

Creating an argument parser itself is already a developer activity, and we don't see that as weird that ‘argparse’ allows for that.

I'm arguing that the library already knows how to turn the argument collection into a user-facing document (the usage message), and a manual page is a different way of rendering that same internal data. So that's why ‘argparse’ is a consistent place to have that functionality.

> 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".

That API already exists: the specific ‘ArgumentParser’ is available to be imported for a program which defines one. So, the library already provides APIs for usage at install time (or any other run-time).

I am asking to make that API more useful for the distribution of programs.