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.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to