Pytest: Option to disable cli log indentation

Created on 28 Jun 2019 · 6Comments · Source: pytest-dev/pytest

Hi,

I have noticed that, the console log output has changed in #5312.

I understand the benefit: the output will be easier to read with eyes.
But in my use-case I have often print generated configurations to the console, and if I wanted to copy-and-paste it, it
will be harder to work with it. I will got unnecessary spaces before my printed configuration (because of the indentation).

Sorry, but I think this change is a little bit strict. I am not against with the change, but it would be good if my "constructed" text could be printed without any change.
Maybe this formatted indentation could be optional (turn on/off with an arg or option)?

If needed I can provide problematic console log.

Thanks

logging help wanted enhancement

Source

mitzkia

👍3

All 6 comments

Hi @mitzkia,

An option seems like a good compromise (logging has tons of options already, another one wouldn't hurt I think). I've changed the title to reflect that. 👍

nicoddemus on 3 Jul 2019

This option is fairly important for me, as some of my log lines are long, and I use a newline to shift the output to the left in order to make the output visible without scrolling an output window, or breaking the line at an artificial location based on terminal size.

I had hoped that \r could be a workaround, as this is defined as moving the output cursor to the beginning of the line. Unfortunately, the call to record.message.splitlines() removes each \r by treating \r as \n, treating \r\n as \n, and treating \n\r as \n\n when splitting. If the method of splitting the lines were adjusted to ignore the \r in \n\r, it would split on the \n and leave the \r at the front of the second line, which would send the cursor to column 0 after printing the indentation, but before printing the text. This would allow another option for formatting the output for readability, as needed, without the requirement to turn the feature on or off everywhere.

This would not address the issue experienced by @mitzkia, so a configuration option would still be advantageous, and may open questions of how it would behave on different platforms such as windows, which may treat \r differently. On the other hand, a character that would trigger a carriage return without a newline (which would visually suppress the automatic indentation) would allow for the default formatting to occur at all times, and still allow for multi-line log entries to (appear to) begin at column 0 of the output on an ad-hoc basis.