On 30/07/2023 21.30, Michał Górny wrote:
> On Sun, 2023-07-30 at 16:26 +0200, Maciej Barć wrote:
>> +# @FUNCTION: nuget_uris
>> +# @USAGE: <nuget...>
>> +# @DESCRIPTION:
>> +# Generates the URIs to put in SRC_URI to help fetch dependencies.
>> +# If no arguments provided, uses the "NUGETS" variable.
> 
> Sounds like you're copying the old, horribly slow cargo.eclass API.
> Don't do that, unless you have to.  Prefer variable-setting approach
> used by modern cargo.eclass.

Should we make this a policy then?

On the other hand, I also wonder if its worth it.

You gave a similar comment when reviewing gradle.eclass and you changed 
the cargo.eclass to also provide the "variable-setting approach" [1].

However, while the $() construct in shells is relatively expensive due 
to the involved forking, it is usually only harmful when used in loops 
with a high iteration count. The loop in go-modules.eclass was a prime 
example of this. The loop was later fixed [2], and I can not help to 
think that this fix caused people to look for further usages of the fork 
construct.

Providing a better UX by increasing performance is good. Nevertheless, 
this should not become a which hunt.

The usage of cargo_carte_uris/ngutes_uris/gradle_src_uri is not in a 
large loop, therefore the situation is not comparable with the one in 
the go-modules.eclass [2].

Which problem are we solving by moving away from this towards a slightly 
more verbose construct?

- Flow


1: 59dbfb80f748 ("cargo.eclass: Add variable alternative to 
$(cargo_crate_uris)")
    https://github.com/gentoo/gentoo/commit/59dbfb80f748

2: 45e7aecd81e0 ("go-module.eclass: inline _go-module_gomod_encode()")
    https://github.com/gentoo/gentoo/commit/45e7aecd81e0