On 02/26/2018 11:58 AM, Michał Górny wrote: > 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.
We can deprecate both aux_get and async_aux_get after an alternative API is available in a stable release of portage. -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature
