cool-easter-32542
01/10/2025, 5:23 AM[stats].log = true configured, which is helpful for experienced users to reference occasionally, but is usually just noise, and especially so for new users.
This logging output can end up jammed up against other real/relevant output of the tool, and thus someone scanning for messages can easily miss it. For example, the first thing CI usually does is ./pants tailor --check, and the output when there's something missing looks like:
Would update BUILD:
- Add python_sources target root
To fix `tailor` failures, run `./pants tailor`.
10:05:26.27 [INFO] Counters:
backtrack_attempts: 0
local_cache_read_errors: 0
local_cache_requests: 0
local_cache_requests_cached: 0
...
Colored:
image▾
./pants tailor. Someone new to using pants wouldn't be aware of ./pants tailor as a thing, and someone more experienced can still benefit from the clear reminder.
This issue is a bit squishy/not-really-concrete bug, but I think there's some potential ways to improve this:
• tweak the styling of debug-style logging like this counters output (automatically applies across all such messages in CI):
• more spacing around debug-style logging
• use colours to deemphasise it, e.g. 'fade' it by setting the colour to grey
• use colours more in messages (requires updating individual messages, of which an intro command like ./pants tailor is potentially a single high-value example and similarly for update-build-files), e.g.:
• add a help heading: `` help: to fix tailor failures, run ... `` prompt similar to rustc, and the heading can be emphasised
• add colours within the "To fix ..." line itself
• another way to get the benefit of the [stats].log = true when required, without pessimising the common case: is it possible to write only to pants.log?
For instance, as a sketch:
image▾
cool-easter-32542
01/10/2025, 5:23 AM