> On 29 Sep 2021, at 22:52, A Schenck <lane_and...@hotmail.com> wrote: > > [snip]
> 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. > Valid point, and I wish that we could get more useful information out of Portage with easy APIs. > 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? Note that this isn't just for ago's purposes. One, it makes it easier to generally grep or parse portage output, but also (very importantly), it makes Portage's output more _accessible_. Right now, Portage is *way* too reliant on colour, which isn't very helpful for colourblind or eyesight impaired users/developers. > -A > >> >> 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 best, sam
signature.asc
Description: Message signed with OpenPGP