Allow user to choose from click and argparse

[csala]

This is arguably a subjective preference, but I would advocate against using Click, in favor of argparse.

Among other things, the main reason is that for Click to work, the code needs to be prepared for that.
On the contrary, argparse can be used to call any function, even if it was previously not prepared to be run directly from the command line interface.

Another reason is that argparse does not introduce any third party dependency, as it is part of stdlib, while click does.

Further details of this discussion can be seen here: https://medium.com/@collectiveacuity/argparse-vs-click-227f53f023dc

Another option would be to remove the cli.py module from this template altogether, as most of the projects end up implementing the CLI commands somewhere else anyway.

[micahjsmith]

Sounds fine to make argparse the default CLI library, I have no strong preference. Lets keep Click as an option because some people strongly prefer it and we don't need to make a judgment.

It should not be a problem to have Click as a non-stdlib dependency as it is frequently a dependency of other libraries anyway. Let's keep cli.py in as an opinionated way to develop a cli. It is a suboptimal pattern IMO to have CLI functionality scripts/foo.py, scripts/bar.py as we have in some HDI projects right now.

[csala]

Since having the cli.py is optional, I agree on keeping it.
Regarding argparse vs click, do you mean making it a new cookiecutter optional?

If so, I agree on doing that.

[micahjsmith]

Yes, I would say make it three options: argparse (default, creates cli.py with stub argparse-base cli), click, and none (does not create cli.py)

…

On Thu, Sep 20, 2018 at 14:15 Carles Sala ***@***.***> wrote: Since having the cli.py is optional, I agree on keeping it. Regarding argparse vs click, do you mean making it a new cookiecutter optional? If so, I agree on doing that. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFOFRtbekQJ9pMB24jO5awnQft20ZLtwks5uc9tBgaJpZM4WtvV2> .

[micahjsmith]

Look into the usage of __main__.py, especially for python -m switch, and also for overall cli implementation.

[micahjsmith]

We propose to add a __main__.py to enable the python -m switch

We also are considering two options:

• implement the CLI in cli.py and import from there a single driver function to __main__.py
• implement all CLI functionality in __main__.py and remove the cli.py file

In the course of considering these options, we are surveying existing OSS projects to see which conventions are widely used and evaluating the evidence for and against.