importlib.metadata, provided by python3-core, contains several imports that are not contained within python3-core, but are provided by separate packages. This issue has been found both on Kirkstone and Scarthgap. The two imports that stick out are "import email" (provided by python3-email) and "import zipfile" (provided by python3-compression). I found this by hitting import errors for import zipfile on some builds that use a native python3 module that includes "import importlib.metadata". I would think a remediation would be to pull out importlib.metadata into a separate module and add the proper runtime dependencies, however there already exists a python3-importlib-metadata recipe provided by meta-python in meta-oe, for limited Yocto versions that uses the name. This package pulls in the separate importlib-metadata package that isn't provided in the Python stdlib and uses the "importlib_metadata" namespace instead of "importlib.metadata". # References ## cpython source: https://github.com/python/cpython/blob/3.10/Lib/importlib/metadata/__init__.py https://github.com/python/cpython/blob/3.12/Lib/importlib/metadata/__init__.py ## kirkstone configs: core: https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/python/python3/python3-manifest.json?h=kirkstone#n248 zipfile: https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/python/python3/python3-manifest.json?h=kirkstone#n192 email: https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/python/python3/python3-manifest.json?h=kirkstone#n591 ## Scarthgap configs: core: https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/python/python3/python3-manifest.json?h=scarthgap#n266 zipfile: https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/python/python3/python3-manifest.json?h=scarthgap#n209 email: https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/python/python3/python3-manifest.json?h=scarthgap#n602 ## Existing python3-importlib-metadata-package https://layers.openembedded.org/layerindex/recipe/414799/
Colin, Notes from the YP bug review meeting... Does this happen on the master branch? The history is that we have granular control of importing but sometimes, we miss upstream changes. Specifically email and zipfile do seem odd. How big are those modules and what are their dependencies? Python has a tool to check for correct dependencies. Ross is going to dig up some info and share it here.
The fix will probably need to be in the python3 manifest file. email: https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/python/python3/python3-manifest.json#n563 zlib (in the python3-core subpackage): https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/python/python3/python3-manifest.json#n267 I'm not seeing importlib/metadata path in the manifest, so more digging is required. What is happening in upstream python ecosystem is that a lot of the stdlib and other core tools are being developed externally, in other repositories. It is getting harder and harder to follow those changes and threads in a casual manner... We could also probably do with some more scrutiny on updates to python3 and the impact on the manifest file.
Just as an experiment with latest **master**: core-image-minimal with IMAGE_INSTALL:append = " python3-core" root@qemux86-64:~# python3 Python 3.13.7 (main, Aug 14 2025, 11:12:11) [GCC 15.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. warning: can't use pyrepl: No module named 'msvcrt' >>> import importlib.metadata Traceback (most recent call last): File "<stdin>", line 1, in <module> import importlib.metadata File "/usr/lib/python3.13/importlib/metadata/__init__.py", line 7, in <module> import json ModuleNotFoundError: No module named 'json'
Stuff like the failure Tim pointed out is exactly why I'm a fan of revisiting the package splitting entirely. I'm thinking it's worth seeing if there's just a few large modules that can be split out to keep the bulk of the standard library in "core" because there's just so much use between parts.
Filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=16019 about revisiting the split.
I suspect the meta-oe module is no longer relevant to us and can be dropped. That would let us package the core separately and resolve the issue? As Ross says, there are other issues too but we can take this step by step...