W dniu pon, 26.02.2018 o godzinie 10∶09 -0800, użytkownik Zac Medico napisał: > On 02/26/2018 04:29 AM, Michał Górny wrote: > > W dniu nie, 25.02.2018 o godzinie 17∶50 -0800, użytkownik Zac Medico > > napisał: > > > Add async_aux_get method that returns a Future and otherwise > > > behaves identically to aux_get. Use async_aux_get to implement > > > the synchronous aux_get method. > > > > > > Bug: https://bugs.gentoo.org/648790 > > > --- > > > pym/portage/dbapi/porttree.py | 91 > > > +++++++++++++++++++++++++++++++++---------- > > > 1 file changed, 70 insertions(+), 21 deletions(-) > > > > > > > What's the exact use case? What's the gain, in numbers? > > I'm planning to use the for repoman, since it commonly has to generate > metadata for multiple packages a once, when dealing with ebuild or > eclass modifications. > > The gain in numbers is that it scales linearly with the number of > available cores. > > > This seems like a lot of added complexity. > > It doesn't really add complexity, asynchronous code or this sort is > already used throughout portage internals. Asynchronous methods like > these are quite standard today, thanks to asyncio. > > > With Portage being practically unmaintainable, > > Any reasonably complex codebase appears to be unmaintainable to those > who don't maintain it. > > > I'm against any changes that make things worse without > > clearly defined major benefit. > > Transitioning to asynchronous interfaces like this is unavoidable as we > move into the realm of asyncio compatibility.
I think we can agree that functions like aux_get() that rely on callers providing constant parameters to obtain the necessary output are far from optimal. I believe Portage should aim towards transitioning callers to more object-oriented APIs. That's why I'm opposed to *proliferating* bad APIs. Maybe I'm wrong but I don't believe this code would be helpful in transitioning Portage to object-oriented API. -- Best regards, Michał Górny
