Re: [gentoo-portage-dev] [PATCH 1/2] portdbapi: add async_aux_get method (bug 648790)

[Michał Górny]

W dniu pon, 26.02.2018 o godzinie 11∶40 -0800, użytkownik Zac Medico
napisał:
> On 02/26/2018 11:23 AM, Michał Górny wrote:
> > 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 fine but aux_get is a public API that will remain supported until
> we have a replacement, and async_aux_get will be an immediately useful
> enhancement to an existing API.

No, it will become a new public API which we will end up supporting
forever.

>
> > 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.
>
> I'd welcome the addition of new APIs, but that should not block the
> enhancement of existing APIs.

-- 
Best regards,
Michał Górny