| Summary: | ParseError exception raised when recipe is indirectly using PLY | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Etienne L <elessard> |
| Component: | bitbake | Assignee: | Paul Barker <paul> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | minor | ||
| Priority: | Medium | CC: | poky.bs.watcher, poky.watcher, randy.macleod |
| Version: | 4.2 | ||
| Target Milestone: | 5.99 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Etienne L
2023-03-14 16:37:12 UTC
A difficult to fix bug but you have a work-around. Any ideas on how to fix it? > Any ideas on how to fix it?
Not really unfortunately. I must admit I didn't take the time to fully understand it, but my first impression was that it came down to the fact that the PLY library has some global module state and thus needs to be used only by a single "thing" at a time, and this was breaking down when using both the YP sstate logic + cffi (through PyCryptodome).
I guess if the copy of PLY that bitbake is vendoring was named differently (and it's assuming bitbake is only using it through pysh), I guess that would be one way to dodge the issue, but that sounds like a rather ugly hack, not sure I would recommend that.
Otherwise, I feel like I don't understand well enough to suggest something.
One of my goal by opening this issue was to at least give it some public exposure, maybe it won't be fixed but at least if someone has the same issue I had and stumble on this bug report, that person will spend a bit less time scratching its head.
I forgot to mention, in my case this was especially confusing since our recipes used to work on YP Dunfell, it's when we migrated to a more recent version of YP that we got these errors. Thanks for the report for making your expectations clear. We have the bug in the 4.99 milestone which is essentially tag indicating that it's a valid bug but not something we have time or people to work in in the forseeable future. It's less urgent than even a 4.2 or 4.3 bug that is unassigned. As you say, perhaps your report will help someone out. Bulk move from 4.99 or 0.00 to 5.99 Paul to explain that this is not a supported workflow and to suggest alternatives. Importing arbitrary python modules inside bitbake tasks is unfortunately not something we can support. If you need to use such a module, the trick is to make the task write out a python script and execute it, that way the import happens in a separate python invocation. The DEPENDS list for the recipe would need to include python3-native and a -native recipe for each Python library used (other than the standard library modules). |