Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Francesco Riosa]

Il giorno mer 29 set 2021 alle ore 23:52 A Schenck <lane_andrew@×××××××.com>
ha scritto:

> On 9/28/21 8:36 AM, Michał Górny wrote:
> > Hi, everyone.
> >
> > I know I'm going to regret asking this... but I've prepared a change to
> > the Portage output format and I think it asks for a wider discussion
> > than internally in Portage team.
> >
> > The primary problem with the current output format is that different
> > kinds of messages differ only in color.  This makes them
> > indistinguishable without colors and hard to grep.  ago's been asking
> > for a better way to grep for QA warnings and this is pretty much what
> > motivated me to do this.
> >
> > The proposed new format distinguished message types both using colors
> > and strings.  This is roughly inspired by Xorg logs.  For example,
> > instead of:
> >
> >  * some message
> >  * other message
> >  * hell if i know what this is
> >
> > You get:
> >
> > [WW] some message
> > [EE] other message
> > [QA] hell if i know what this is
> >
> > I've also added more colors to explicitly distinguish einfo from elog,
> > and ewarn from eqawarn.  Then, I've replaced most of '>>>' and '!!!'
> > used by Portage with four-character versions to keep messages aligned.
> > The 'zings' used for merging files remain three-character, so now it's
> > easily possible to distinguish messages from installed file list.
>
> Didn't expect to be the only dissenting opinion on something like this
> but. . . Some applications parse portage output looking for these
> 'zings'. At very least app-portage/kuroo does it this way; there must be
> others, right? This is obviously not the ideal way to get information
> out of portage, but it's been stable for the 15 years Kuroo has existed.
> 10-ish years ago dol-sen started some work on building and API for
> portage, but then got sucked into core portage development to the point
> of abandoning their GTK+ portage GUI porthole, which was the original
> impetus for an API, and as far as we know, the API never made it to the
> point it could replace parsing the output.
>
> It wouldn't be worth blocking progress for one application that not many
> people use, but assuming there are others that will also break with this
> change. Are we sure there's no way to support ago's (very valuable) work
> without breaking other things?
>
> -A
>

Kuroo is already a quite complex application that parse portage output. A
quick grep seems to show that changes needed are quite manageable.
Also the parsing should be more accurate with proposed changes.
Rather it should be easy for the application to know in advance which
format the output will be.
There is also the opportunity to have a flag that enable (or disable) the
augmented output, but IMHO this should be done only if the added complexity
is NIL

$ grep -c  -Ers 'QRegExp |QregularExpression ' -i kuroo-1.2.1  | grep -v
:0$
kuroo-1.2.1/TODO:1
kuroo-1.2.1/src/history/history.cpp:3
kuroo-1.2.1/src/config/configdialog.h:2
kuroo-1.2.1/src/queue/queuelistview.cpp:1
kuroo-1.2.1/src/core/scanupdatesjob.cpp:1
kuroo-1.2.1/src/core/global.h:2
kuroo-1.2.1/src/core/packageinspector.cpp:4
kuroo-1.2.1/src/core/packageversion.h:2
kuroo-1.2.1/src/core/etcupdate.h:1
kuroo-1.2.1/src/core/portagedb.cpp:2
kuroo-1.2.1/src/core/scanhistoryjob.cpp:3
kuroo-1.2.1/src/core/global.cpp:1
kuroo-1.2.1/src/core/dependatom.h:2
kuroo-1.2.1/src/core/emerge.cpp:8




>
> >
> > The PR doing this is: https://github.com/gentoo/portage/pull/759
> >
> > Example screenshot:
> >
> https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png
> >
>
>