Not sure how you feel about this, if you don't like it, that's fine, I'll hack it locally then.

While the dominant use-case for a parser is in a batch-oriented program that you run from the command line, parsers are also used in other contexts. One big example is running in the background of an editor as compiler frontend to give GUI feedback while the user is editing. In my case, I intend to use your parser at a web server, as a compile service.

There is no "unix command-line" inside a web server (or an editor). I don't want to install 'click' at the server, as it's completely useless in that environment. If I want fancy coloured and formatted output (and I am far from sure about that currently), it would need to be HTML rather than some terminal escape sequences, or the web client can't display it.

Not installing 'click' currently breaks the parser, due to aparser -> exceptions -> termui -> click import chain. This patch make the final link optional, by allowing the click import to fail, which then falls back to standard Python stuff.

I have not tested this extensively yet, since I am still in the process of getting the grammar figured out and attaching actions to it. I thought it to be wise to ask you about this early in the process. If you are not interested, I will just hack a local patch until it works for me.

There is at least one other thing that looks scary to me, all the styled messages in the exceptions. I'll have to test how that behaves, but I need a working grammar/compiler for that first.

One possible direction can be to make exception objects just store the exceptions (and nothing else), and have a separateparglare.pretty_print module, that canpretty_print(my_exception). Slightly less nice thanprint(str(my_exception)) but more useful in environments that have no unix terminal.