Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Alejandro Hernandez <alhe@linux.microsoft.com>
To: richard.purdie@linuxfoundation.org,
	openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 3/4] python_pep517.bbclass: always export _PYTHON_HOST_PLATFORM for wheel tag
Date: Thu, 6 Aug 2026 11:28:58 -0600	[thread overview]
Message-ID: <c5e82305-005a-454c-8b23-502870014209@linux.microsoft.com> (raw)
In-Reply-To: <c5594afab73a3a5627aa694bb4b879e38f855382.camel@linuxfoundation.org>

[-- Attachment #1: Type: text/plain, Size: 4470 bytes --]


On 8/6/2026 10:09 AM, Richard Purdie via lists.openembedded.org wrote:
> On Thu, 2026-08-06 at 09:51 -0600, Alejandro Hernandez wrote:
>>   
>>
>>
>>   
>>
>>   
>>
>> On 8/6/2026 6:26 AM, Richard Purdie via lists.openembedded.org wrote:
>>   
>>
>>   
>>
>>>   
>>>
>>> On Tue, 2026-08-04 at 22:04 +0000, Alejandro Hernandez Samaniego via lists.openembedded.org wrote:
>>>   
>>>
>>>>   
>>>>
>>>> python distutils/sysconfig.get_platform() falls back to
>>>> distutils.util.get_platform() when the _PYTHON_HOST_PLATFORM
>>>> environment variable is unset, and returns the *build host* arch.
>>>> The result is baked into the produced wheel's filename
>>>> (pkg-<ver>-cp3XX-cp3XX-<PLAT>.whl) and its <pkg>.dist-info/WHEEL
>>>> metadata.
>>>>
>>>> Without this export, extension-module wheels tag themselves with
>>>> whichever arch the autobuilder worker happens to have, which makes
>>>> the resulting rpm non-reproducible across mixed-arch autobuilder
>>>> pools.
>>>>
>>>> Since python 3.14 + wheel >=0.44 also rejects wheels with an empty
>>>> platform tag ("Bad wheel filename"), the value has to be non-empty
>>>> in every class scope. HOST_ARCH is class-scoped by bitbake
>>>> (target/native/cross/nativesdk), so `linux-${HOST_ARCH}` covers
>>>> every case with a single unconditional assignment. Setting per-class
>>>> overrides to "" (as an earlier draft did) trips the wheel filename
>>>> check and must be avoided.
>>>>
>>>> Pure-python wheels ignore _PYTHON_HOST_PLATFORM and remain tagged
>>>> "any", so this change only affects wheels that ship compiled
>>>> extensions (cffi, cryptography, numpy, bcrypt, markupsafe, psutil,
>>>> rpds-py, websockets, ...).
>>>>
>>>> Assisted-by: AI - OpenAI
>>>> Signed-off-by: Alejandro Hernandez<alhe@linux.microsoft.com>
>>>> ---
>>>>   meta/classes-recipe/python_pep517.bbclass | 16 ++++++++++++++++
>>>>   1 file changed, 16 insertions(+)
>>>>
>>>> diff --git a/meta/classes-recipe/python_pep517.bbclass b/meta/classes-recipe/python_pep517.bbclass
>>>> index d6246af5c2..06b23d3cba 100644
>>>> --- a/meta/classes-recipe/python_pep517.bbclass
>>>> +++ b/meta/classes-recipe/python_pep517.bbclass
>>>> @@ -30,6 +30,22 @@ PEP517_INSTALL_PYTHON:class-native = "nativepython3"
>>>>   # pypa/installer option to control the bytecode compilation
>>>>   INSTALL_WHEEL_COMPILE_BYTECODE ?= "--compile-bytecode=0"
>>>>   
>>>> +# Force the wheel's platform tag to reflect the target machine rather than the
>>>> +# build host. Without this, extension-module wheels bake the build host's arch
>>>> +# (e.g. linux_x86_64) into <pkg>.dist-info/WHEEL via distutils/sysconfig's
>>>> +# get_platform(), which breaks reproducibility across autobuilder workers of
>>>> +# different architectures. Pure-python wheels ignore this variable and remain
>>>> +# tagged "any".
>>>> +#
>>>> +# HOST_ARCH is class-scoped by bitbake:
>>>> +#   - target:     HOST_ARCH == TARGET_ARCH (reproducible across workers)
>>>> +#   - native:     HOST_ARCH == BUILD_ARCH  (matches worker arch, unpackaged)
>>>> +#   - cross:      HOST_ARCH == BUILD_ARCH
>>>> +#   - nativesdk:  HOST_ARCH == SDK_ARCH
>>>> +# so a single expression covers every class without producing an empty tag
>>>> +# (which python 3.14 + wheel >=0.44 rejects with "Bad wheel filename").
>>>> +export _PYTHON_HOST_PLATFORM = "linux-${HOST_ARCH}"
>>>>   
>>>>
>>>   
>>>
>>> The fix looks right, thanks!
>>>
>>> I'm not sure we need the 10+ lines of explanation from AI ;-) The
>>> commit message could be more concise too. We're seening way too much
>>> text being added by AI in general and it will make the codebase harder
>>> to understand in the long run :(.
>>>
>>> Cheers,
>>>
>>> Richard
>>>   
>>>
>>   
>>
>> I agree, I can send a v2 or just keep it in mind for next time, let me know.
> v2 please, it is too verbose and I would have to manually trim it...
>
> Cheers,
>
> Richard

Sent v2

Cheers!

>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#242955):https://lists.openembedded.org/g/openembedded-core/message/242955
> Mute This Topic:https://lists.openembedded.org/mt/120602086/4354175
> Group Owner:openembedded-core+owner@lists.openembedded.org
> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [alhe@linux.microsoft.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

[-- Attachment #2: Type: text/html, Size: 5857 bytes --]

  reply	other threads:[~2026-08-06 17:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04 22:04 [PATCH 1/4] libtool: strip build system triplet from installed libtool script Alejandro Hernandez
2026-08-04 22:04 ` [PATCH 2/4] ptest.bbclass: strip build machine triplet from installed ptest Makefiles Alejandro Hernandez
2026-08-04 22:04 ` [PATCH 3/4] python_pep517.bbclass: always export _PYTHON_HOST_PLATFORM for wheel tag Alejandro Hernandez
2026-08-06 12:26   ` [OE-core] " Richard Purdie
2026-08-06 15:51     ` Alejandro Hernandez
2026-08-06 16:09       ` Richard Purdie
2026-08-06 17:28         ` Alejandro Hernandez [this message]
2026-08-04 22:04 ` [PATCH 4/4] bitbake.conf, rust-common.bbclass: include RUST_BUILD_SYS in the task hash Alejandro Hernandez
2026-08-06  5:58   ` [OE-core] " Mathieu Dubois-Briand
2026-08-06 15:53     ` Alejandro Hernandez
2026-08-06 12:53   ` Richard Purdie
2026-08-06 15:50     ` Alejandro Hernandez
2026-08-06 16:12       ` Richard Purdie
     [not found] ` <18C8B9671621C916.3417489@lists.openembedded.org>
2026-08-05  4:16   ` Alejandro Hernandez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c5e82305-005a-454c-8b23-502870014209@linux.microsoft.com \
    --to=alhe@linux.microsoft.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox