Removal of click dependency

[lewer]

Hi,

The click library is used in panflute, but only here:

panflute/panflute/autofilter.py

Lines 166 to 177 in dd8b03a

	@click.command(help=help_str)
	@click.argument('filters', nargs=-1)
	@click.option('-w', '-t', '--write', '--to', 'to', type=str, default=None,
	help='Output format passed to Pandoc (and filters).')
	@click.option('--dir', '-d', 'search_dirs', multiple=True,
	help="Search filters in provided directories: `-d dir1 -d dir2`.")
	@click.option('--data-dir', is_flag=True, default=False,
	help="Search filters in default user data directory listed in `pandoc --version` " +
	"(in it's `filters` subfolder actually). It's appended to the search list.")
	@click.option('--no-sys-path', 'sys_path', is_flag=True, default=True,
	help="Disable search filters in python's `sys.path` (without '' and '.') " +
	"that is appended to the search list.")

This can be easily replaced with standard lib's argparse, and then click could be removed. It would be one less dependency.

Do you agree with a PR proposing this?

[sergiocorreia]

I've gotten used to click in other packages (easier than argparse) so I have a slight preference for relying on it.

That said, is there something that makes you prefer a click-less approach?

[lewer]

I have nothing against click and use it also in some projects. If you have a complex CLI with for instance subcommands and don't want the hassle of doing it with argparse, why not using click.

But here there's only a single command, with a few options. It would easily translate to argparse syntax, and would achieve the same behavior. The benefit is that you reduce the external dependencies of panflute; users who install panflute (like me :-)) don't have to install click also, click can be removed from the CI, etc. It's not a huge improvement, but if it doesn't cost anything...

[mfhepp]

In the light of supply-chain attacks on Python dependencies, simplifying the dependency graph is generally a good thing. But as for Click, I tend to see the benefits outweigh the costs. CLI interfaces with Click (or Typer, which is an even nicer wrapper around Click) are so much more readable than argparse stuff.

And a panflute-based project will have additional dependencies in a requirements.txt or environment.yaml anyway.

So I would argue for a readable and maintainable CLI implementation and hence for keeping the dependency. But no strong opinion either.