Occasionally most (all?) python recipes fail to compile with: error: invalid command 'egg_info' Running `bitbake -c clean` for the affected recipes get them back to working. I have not figured out what triggers the problem or a way to reproduce it. It typically happens after updating the openembedded-core layer so my guess is that it is related to some tasks being fetched from the sstate cache, and some tasks having to rebuild. Here is a full error log for `python3-calver-native`: DEBUG: Executing shell function do_compile + cd .../qemux86-64-alt/tmp/work/x86_64-linux/python3-calver-native/2025.10.20/sources/python3-calver-2025.10.20 + do_compile + python_pep517_do_compile + pyproject-build --no-isolation --wheel --outdir .../qemux86-64-alt/tmp/work/x86_64-linux/python3-calver-native/2025.10.20/dist .../qemux86-64-alt/tmp/work/x86_64-linux/python3-calver-native/2025.10.20/sources/python3-calver-2025.10.20 * Getting build dependencies for wheel... usage: _in_process.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: _in_process.py --help [cmd1 cmd2 ...] or: _in_process.py --help-commands or: _in_process.py cmd --help error: invalid command 'egg_info' ERROR Backend subprocess exited when trying to invoke get_requires_for_build_wheel
Also reported by people on IRC.
The hunch is that this is due to an upgrade happening to dependencies which leaves an empty directory in site-packages, which importlib then reports as a module although it has no metadata. There's an upstream bug somewhere, and I can dig out the fix we'd previously applied. For now, cleaning is acceptable...
This seems to happen for recipes that inherit `setuptools3` or `python_setuptools_build_meta` when there is stale sstate cache. Or at least `bitbake -c cleansstate python3-pytest` worked for me (several other recipes needed the same). Ross maybe correct that only `bitbake -c clean` is needed. I did not test that.
s/Ross/Ross and Peter/
(In reply to Tim Orling from comment #3) > This seems to happen for recipes that inherit `setuptools3` or > `python_setuptools_build_meta` when there is stale sstate cache. Or at least > `bitbake -c cleansstate python3-pytest` worked for me (several other recipes > needed the same). Ross maybe correct that only `bitbake -c clean` is needed. > I did not test that. I think it's not because of sstate but workdir. It happened to me only with stale workdir/tmpdir. Simple clean (not cleatsstate) and/or buiding on the builder with shared sstate but with completely new tmpdir solves the problem.
After Ross' comment, I had a feeling of déjà vu. And it turned out to be right. I have apparently been bothered by this before, and after some searching in the logs, I found commit 47d9d90b4ec7d04d6f3f1a9b97c0ab7f1264a88e "meson.bblcass: Remove empty egg-info directories before running meson", where I apparently solved this problem for Meson based projects. However, it appears a more generic solution is needed...
There is also commit 73de8daa6293403f5b92d313af32882c47bce396 "python3: backport the full fix for importlib scanning invalid distributions" by Ross, where a local patch that seems to have ignored empty directories supposedly have been replaced by some upstream fix.
And of course, further investigation of the logs show that my commit (47d9d90b4ec) was reverted in commit ebdb49b9292bf8e61ef0a3f56ff76fcab3ac503f because RP had in fact added a more generic solution in commit e5944a38db513e033c3a3e9313267055f7254be7 "python3: Ensure stale empty python module directories don't break the build". This was the one that Ross later reverted in commit 73de8daa62. So either that backported patch (meta/recipes-devtools/python/python3/valid-dists.patch, which we apparently still have) did not actually solve the problem of empty directories, or upstream has broken them yet again...
My memory is that the upstream fix we proposed was quite deep in the importlib code and they wanted to return "empty" modules to the caller, so we should go and fix the callers.
Root-caused and filed a ticket and two potential fixes upstream: https://github.com/python/importlib_metadata/issues/534
PATCH ON THE LIST.
Fixed in oe-core 855d1111c3da40edc05ec300839f7003a388e3c4.