click VS python-prompt-toolkit

Context: "click" - "Command Line Interface Creation Kit" - easily create CLIs from Python code, via adding decorators: https://github.com/pallets/click

"click-web" in turn turns the click CLI app into a web app with one line of code.

there is also click, it is more straight forward and also nice to keep the relevant code where the code is. https://github.com/pallets/click/

I don't have huge experience with Python, but I used async code with C#/Typescript and lately I had to use some asyncio magic.

I found this article: https://blog.dalibo.com/2022/09/12/monitoring-python-subproc... and while async/await syntax is the same, it's not entirely clear for me, why there's some event loop and what exactly happens, when I pass function to asyncio.run(), like here: https://github.com/pallets/click/issues/85#issuecomment-5034...

So, you can use it and it's not that hard, but there are some parts that are vague for me, no matter which language implements async support.

Hmm… did you try such approaches, as [click](https://github.com/pallets/click) or[tap](https://github.com/swansonk14/typed-argument-parser)?

This app leverages these powerful libraries: - yt-dlp: video downloader - moviepy: video trimmer/merger - click: CLI app creator - rich / rich-click: CLI app styler

I've used click [1] a lot to build Python tooling scripts the past few years. Click usage is "sort of" similar to the author's proposed solution. There's also a small section here [2] that describes some of the issues covered in the article (in context of argparse).

[1] - https://github.com/pallets/click

I think the success of Arduino in the hardware world can be explained in a similar way, as the relative success of "command line app frameworks" like Click[1], or even much lighter-weight libraries like argparse[2]. You absolutely can get away with using just getopt[3] (and people experienced with it will likely strongly prefer it). However certain factors such as a more declarative API, a nice logo, the existence of an ecosystem (even if you're not actively drawing from it), an official "branded" forum, etc can all play into picking a more complex solution, with more baggage you don't need, certain oddities that may throw users off, etc.

[1]: https://click.palletsprojects.com/

[2]: https://docs.python.org/3/library/argparse.html

[3]: https://man.openbsd.org/getopt.3, https://linux.die.net/man/3/getopt

Exactly! You can also use a library like click (https://github.com/pallets/click) to help take care of the command line side, while you focus on the 'business logic' of your application :)

Ref. https://github.com/prompt-toolkit/python-prompt-toolkit and https://github.com/c-bata/go-prompt ?

> The purpose is not to do this however, the goal for a repl cli is usually to invoke a set of particular, already implemented commands, not on the fly python input and output. The implementation will be predefined and packaged, repl are only used to run a list of specific commands with arguments that implementation has already defined.

That's a very strange definition for a REPL, I would just call that an (interactive) CLI. Maybe that's why you couldn't find anything when you were doing your search? I used python-prompt-toolkit [0] when building such interfaces. pgcli [1] is an example of such an interface built with prompt-toolkit.

It has a lot of nice autocomplete and readline emulation options. Maybe it's something you can integrate with your project.

[0] https://github.com/prompt-toolkit/python-prompt-toolkit

[1] https://www.pgcli.com/

Euporie uses prompt_toolkit as its TUI library. prompt_toolkit does not specifically support terminal graphics, but I've written various of custom components and modifications to enable images to be displayed using terminal graphics.

That bothered me too, the default function for Ctrl-W in ipython is unix-word-rubout from python-prompt-toolkit [1], which uses spaces for word boundaries. You can rebind it to backward-kill-word so it uses "not a letter nor a digit" as a word boundary.

Here's a gist with my config (also binds shift-left/right arrow to move to previous space instead of visual select): https://gist.github.com/fratajczak/64e32421a43d3b8194d0409ce...

[1]: https://github.com/prompt-toolkit/python-prompt-toolkit/blob...

When coding in python I've used ptpython repl based on prompt-toolkit which has been used in numerous CLI programs https://github.com/prompt-toolkit/python-prompt-toolkit/blob/master/PROJECTS.rst. I've also used mycli from that page. I've really enjoyed the UX of these. In addition to the syntax highlighting, auto/tab completions, (and maybe other enjoyable features) the vi-mode is amazingly helpful (for us vi folks) (it's probably got emacs bindings too). I would love to have all of this in a repl for lua.

That's an interesting approach. I was also thinking of using a more sophisticated framework than whiptail, maybe the PromptToolkit. I guess it then would be more similar to the idea of using a text editor. I certainly do think a TUI may be overkill yet it was also a good excuse to practice some bash scripting for me.

Try prompt_toolkit which is a Python library used by IPython among others: https://github.com/prompt-toolkit/python-prompt-toolkit