wntrblm / nox

Flexible test automation for Python
https://nox.thea.codes
Apache License 2.0
1.3k stars 148 forks source link

Add option to limit the logged arguments #826

Open FredStober opened 4 months ago

FredStober commented 4 months ago

When running nox from within pre-commit, the argument list can be quite large and fill several screens. In most cases, the interesting thing is not the whole used command line argument but just the first few options. Therefore, I've added a new option 'max_log_args' that allows to limit the number of arguments that are shown in the logging output.

FredStober commented 4 months ago

Sorry, I forgot to commit a line to tests/test_sessions.py

cjolowicz commented 4 months ago

Does this need to be a built in Nox feature? I suppose you're passing the files as session arguments (session.posargs) so in your session function you have full control over what gets logged. You can pass the silent flag to session.run and produce the log line yourself.

FredStober commented 4 months ago

I tried to implement it outside with silence and log=False, but in case of an error, these flags do not apply and my command line with 500 file names (args are managed by pre-commit) gets logged to the console.

Here is one example for something I tried. But even with this command, the failing command line is shown in the console:

with Path('test.err').open('w') as stderr:
   output = session.run('ruff', 'check', *session.posargs, stderr=stderr, silent=True, log=False)

Every other approach I could think of would have modified the behavior of the run function in some more substantial way.

If I add all possible error codes to success_codes to really suppress any kind of logging by nox, I would still need to somehow get to the error code, but the run command does not expose that information - so I would have to extend the run interface (that would be a breaking change I guess...) or manually try to parse the output to determine the outcome.

Hm - on second thought I guess I could use subprocess instead of session.run, since I mostly care about the venv management. But that seems like a pretty strange thing to do.

In the end I don't mind that there is a log of the failing command line - I want it there. It's just that it's too verbose (and I assume I'm not the only one with session.run commands with long argument lists) - hence the PR :)