Use stderr more consistently?

[mwermelinger]

Currently, any errors raised by argparse (like calling allowed -b file.py) go to stderr, everything else goes to stdout, including due to sys.exit().

• Should the latter go to stderr?
• Should final warnings (e.g. method calls were not checked) also go to stderr?
• While processing a folder, should all messages continue to go to stdout, or should those due to exceptions (invalid JSON for notebooks, no file found, etc.) go to stderr?
• If the rationale is that if a file can't be processed, it goes to stderr, then should a syntax error in a .py file also go to stderr, but a syntax error in a cell doesn't?
• Should we also return more exit codes?
• How does a 'logging' output like for #62 fit into this?

What is the approach used by other linters? What do we gain by separating stdout and stderr?

[densnow]

RE exit codes, I like the way ruff does things (see ruff exit codes):

• 0 if no violations were found, or if all present violations were fixed automatically.
• 1 if violations were found.
• 2 if Ruff terminates abnormally due to invalid configuration, invalid CLI options, or an internal error.

The numbers used here are irrelevant (apart from the following of some unix conventions), I like this is because it is consistent and well documented. It makes it easier to integrate with other tools when scripting or using it in pipelines.

It's the same justification for clearly separating stderr and stdout, as was mentioned in #62 when commands are part of pipelines then you don't want error messages mixed in with the data. Of course the majority of use cases for allowed will not involve scripts and pipelines etc, but IMHO it can't do any harm to make integration with other tools easier.

As mentioned, there are a couple of tricky cases in allowed's output that would need consideration, but I think consistency is the key. If syntax errors for .py files go to stderr then so should syntax errors for cells in .ipynb. Abnormal termination and warnings also go to stderr. Anything which is considered normal output for the program (i.e reported violations of the python subset) goes to stdout. A logging output (as per #62) could be considered normal output, and, since it will have an option to switch off, can go to stdout.

[mwermelinger]

While in principle I agree with you, I think this needs looking into how ruff, pylint and others separate stdout and stderr. Since there are higher priority issues to work on for 24J, I'm not going to work on this for now.