[OE-core] [RFC PATCH] package.bbclass: omit .pyc and .pyo file

Burton, Ross ross.burton at intel.com
Wed Jan 7 11:16:49 UTC 2015


On 7 January 2015 at 09:23, Mike Looijmans <mike.looijmans at topic.nl> wrote:

> You definitely SHOULD ship the .pyc files. If they don't exist, the
> interpreter is forced to re-compile the .py source, and will attempt to
> write the result to the filesystem. It won't cause harm, it won't fail, but
> it's very inefficient. It's better to let the host do the py->pyc
> conversion anyway.
>
> The opposite works just fine: You can omit the .py files and ship only
> .pyc files. We do that on settopboxes that use Python for the GUI, this
> saves several megabytes of flash space.
> To accomplish that, we put the .py files into a $PN-src package.
>

I agree with Mike, there is a use-case for just shipping .pyc.  Whether
oe-core should do something to assist with this or not is debatable.

There's an open bug report about this:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6434.

https://docs.python.org/2/tutorial/modules.html#compiled-python-files has
the details we're after.  Summary:

.pyc is Python bytecode, which is an implementation detail of CPython.  As
such it's version-dependent but explicitly architecture-independent.
.pyo generated with -O is simply .pyc but with asserts removed.
.pyo generated with -O -O has asserts and docstrings removed.

I think it's fair to say we should just ignore .pyo - no point generating
and shipping it.  It does seem that if we want to ship usable .pyc we need
to ensure that they are compiled with python-native. I guess this could be
done by calling python-native's compileall module to recompile the sources
at package time.

Ross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150107/60da4bdd/attachment-0002.html>


More information about the Openembedded-core mailing list