Re: [PATCH v3] data: Return a list from exported_vars()

Hi,

On 30/07/2026 20:08, Alejandro Mery wrote:
> exported_vars() was a generator, so each value expanded when the result
> was iterated rather than when it was called. bitbake-worker binds it
> before bb.utils.empty_environment() and iterates it afterwards, so any
> expansion deferred until iteration ran against the wiped environment
> rather than the one bitbake started with.
>
> The corruption is not uniform. The worker writes each variable into
> os.environ as it goes, so only the first value expands against a fully
> empty environment and the rest see it partially rebuilt, in
> exported_keys() order.
>
> Recipes whose exported variables expand a command during that loop hit
> this. A gitver-style PV such as "${@get_git_pv(d, ...)}" runs git while
> PATH is empty, so the git wrapper on PATH is bypassed and the real git
> runs directly. Under pseudo this fakes uid 0 against a repository owned
> by the real user, and git aborts with "detected dubious ownership",
> failing do_package intermittently (only on reparse, when the value is
> re-expanded rather than served from cache).
>
> Build and return the list in exported_vars() itself, so the expansion is
> complete before it returns and no caller has to know it was ever
> deferred. A value that fails to expand now warns at that point rather
> than during iteration, and a result nothing consumes is expanded anyway;
> neither is a change for the one caller, which consumes all of it. Update
> the comment at the worker's call site, which documented the generator
> that is now gone, and add tests for the expansion timing and for the
> warning that moved with it.
>
> - v3: materialise in exported_vars() itself, not at the call site; two
>    tests, using bb.utils.environment() rather than touching os.environ
>    directly.
> - v2: comment the ordering at the call site, and add the tests.
> - v1: the list() wrap alone.
>
> Signed-off-by: Alejandro Mery <[email protected]>

now that this is merged (c870f5bd96ad02efc02c58133c27bdae3a300e3e), 
could it get cherry-picked into 2.18?

Thanks,
Alejandro Mery