| 1 |
On 9/28/21 8:36 AM, Michał Górny wrote: |
| 2 |
> Hi, everyone. |
| 3 |
> |
| 4 |
> I know I'm going to regret asking this... but I've prepared a change to |
| 5 |
> the Portage output format and I think it asks for a wider discussion |
| 6 |
> than internally in Portage team. |
| 7 |
> |
| 8 |
> The primary problem with the current output format is that different |
| 9 |
> kinds of messages differ only in color. This makes them |
| 10 |
> indistinguishable without colors and hard to grep. ago's been asking |
| 11 |
> for a better way to grep for QA warnings and this is pretty much what |
| 12 |
> motivated me to do this. |
| 13 |
> |
| 14 |
> The proposed new format distinguished message types both using colors |
| 15 |
> and strings. This is roughly inspired by Xorg logs. For example, |
| 16 |
> instead of: |
| 17 |
> |
| 18 |
> * some message |
| 19 |
> * other message |
| 20 |
> * hell if i know what this is |
| 21 |
> |
| 22 |
> You get: |
| 23 |
> |
| 24 |
> [WW] some message |
| 25 |
> [EE] other message |
| 26 |
> [QA] hell if i know what this is |
| 27 |
> |
| 28 |
> I've also added more colors to explicitly distinguish einfo from elog, |
| 29 |
> and ewarn from eqawarn. Then, I've replaced most of '>>>' and '!!!' |
| 30 |
> used by Portage with four-character versions to keep messages aligned. |
| 31 |
> The 'zings' used for merging files remain three-character, so now it's |
| 32 |
> easily possible to distinguish messages from installed file list. |
| 33 |
|
| 34 |
Didn't expect to be the only dissenting opinion on something like this |
| 35 |
but. . . Some applications parse portage output looking for these |
| 36 |
'zings'. At very least app-portage/kuroo does it this way; there must be |
| 37 |
others, right? This is obviously not the ideal way to get information |
| 38 |
out of portage, but it's been stable for the 15 years Kuroo has existed. |
| 39 |
10-ish years ago dol-sen started some work on building and API for |
| 40 |
portage, but then got sucked into core portage development to the point |
| 41 |
of abandoning their GTK+ portage GUI porthole, which was the original |
| 42 |
impetus for an API, and as far as we know, the API never made it to the |
| 43 |
point it could replace parsing the output. |
| 44 |
|
| 45 |
It wouldn't be worth blocking progress for one application that not many |
| 46 |
people use, but assuming there are others that will also break with this |
| 47 |
change. Are we sure there's no way to support ago's (very valuable) work |
| 48 |
without breaking other things? |
| 49 |
|
| 50 |
-A |
| 51 |
|
| 52 |
> |
| 53 |
> The PR doing this is: https://github.com/gentoo/portage/pull/759 |
| 54 |
> |
| 55 |
> Example screenshot: |
| 56 |
> https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png |
| 57 |
> |
Archives
