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
