@renanrodrigo I thoroughly enjoyed reading your investigation and explanation of what is happening and why. You also predicted one of the questions I had while reading: "[...] why it's not happening to other python packages that are seeded? Well it may be! haha" - haha indeed! Perhaps seeded package Python caches have been silently rebuilding themselves wasting unknown seconds of CPU on first use ;-)
Looking through https://github.com/python/cpython/blob/3.13/Lib/importlib/_bootstrap_external.py#L1130-L1148 confirms what you said about the validity of the .pyc files being based off the mtime timestamps of the corresponding .py files. Basically if the mtime and size of the .py file isn't EXACTLY what has been embedded within the .pyc file, the .pyc will be considered stale and won't be used resulting in a later attempt to regenerate the .pyc . In terms of options I only see the following: - As you suggested, ensure that .py files always keep their original mtime when there are corresponding .pyc files with the original mtime embedded within - Shift to using hash based verification (at which point timestamps simply don't matter) - Regenerate all .pyc files after .py copying has been completed - Disable .pyc usage at runtime I'm glad my wild speculation and hints proved useful. At least we have a workaround provided by @ahasenack (reinstall the package) for cases where the .pyc can't automatically be regenerated. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2107332 Title: AppArmor denied audit messages related to __pycache__ in dmesg To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/2107332/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
