CLI with minimal/none defaults and writing output to stdout

[bast]

The CLI would require all required input files to be provided and would assume no defaults.

Motivation:

• explicit is better than implicit
• less surprising
• more flexibility for users to name/place files where they like
• when writing output to stdout, we do not need to check whether we overwrite files
• simpler code

Would require a bit more typing but this will be less of a problem for users of the lib than it is now for the developers during debugging.

[robertodr]

Useful tools within Click for refactoring our CLI:

• https://click.palletsprojects.com/en/7.x/utils/#intelligent-file-opening
• https://click.palletsprojects.com/en/7.x/advanced/#token-normalization
• https://click.palletsprojects.com/en/7.x/utils/#printing-to-stdout

[bast]

Postpone until other major changes are in place.

[robertodr]

I'm inclined to completely deprecate usage of parselglossy as parser. If the only way to use the project is to generate parsers, this becomes a non-issue for us.

[bast]

Not sure I understand and maybe what I write here is off-topic but I would find it practical if users of parselglossy can not only generate the code but if they can also test the parsing outside of their code without running through the whole machinery of their code.

I would like to be able to do this:

• generate the code based on template (we have that)
• then create some input, maybe tweak the grammar
• test what dictionary i would get

... before going into my code and spending time hooking up the json bindings etc. To get an early reward and simplify debugging. Also to simplify debugging user requests that parselglossy users get from their codes' users.

[robertodr]

But that can already be done. Assuming input_parser is the generated parsing module:

$ python
>>> import input_parser.api 
>>> input_parser.api.parse(infile, outfile)

[bast]

OK so the decision/question is whether we want to only provide an API or also a CLI. Was this your question?

I'm inclined to completely deprecate usage of parselglossy as parser. If the only way to use the project is to generate parsers, this becomes a non-issue for us.

[robertodr]

I'll open a pull request, easier to discuss in that form.