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?
- Flow1: 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
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
