From: Robert Yang <liezhi.yang@windriver.com>
To: Mike Looijmans <mike.looijmans@topic.nl>,
<openembedded-core@lists.openembedded.org>
Subject: Re: [RFC PATCH] package.bbclass: omit .pyc and .pyo file
Date: Wed, 7 Jan 2015 17:32:10 +0800 [thread overview]
Message-ID: <54ACFD1A.5000606@windriver.com> (raw)
In-Reply-To: <54ACFB02.5060209@topic.nl>
On 01/07/2015 05:23 PM, Mike Looijmans wrote:
> On 01/07/2015 09:07 AM, Richard Purdie wrote:
>> On Tue, 2015-01-06 at 17:07 -0800, Robert Yang wrote:
>>> We should not ship .pyc or .pyo file, but there are a few packages
>>> ship .pyc, should we:
>>
>> Why should we not ship them? Doesn't python create these at runtime if
>> they're not present? What happens on a read only filesystem?
>
> 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.
AFAIK, the .pyc is not version compatible, the .pyc created with the
build host's python may not work with the target python.
// Robert
>
> 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.
>
> There has been general agreement that .pyo files are utterly pointless.
>
>> I'm sure we've had issues raised by someone with a read only filesystem
>> before FWIW.
>>
>> I agree there is probably an issue here but deleting them may not be the
>> best option. I'm open to ideas though.
>
> My idea would be to standardize on shipping ONLY compiled files, and put the
> source .py files into a separate package named $PN-src by default. There is no
> need to install megabytes of python source files that neither users nor the
> interpreter will ever read.
>
>
>
> Met vriendelijke groet / kind regards,
>
> Mike Looijmans
> System Expert
>
>
> TOPIC Embedded Systems
> Eindhovenseweg 32-C, NL-5683 KH Best
> Postbus 440, NL-5680 AK Best
> Telefoon: (+31) (0) 499 33 69 79
> Telefax: (+31) (0) 499 33 69 70
> E-mail: mike.looijmans@topic.nl
> Website: www.topic.nl
>
> Please consider the environment before printing this e-mail
>
> Topic zoekt gedreven (embedded) software specialisten!
> http://topic.nl/vacatures/topic-zoekt-software-engineers/
>
next prev parent reply other threads:[~2015-01-07 9:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-07 1:07 [RFC PATCH] package.bbclass: omit .pyc and .pyo file Robert Yang
2015-01-07 2:07 ` ChenQi
2015-01-07 8:07 ` Richard Purdie
2015-01-07 9:23 ` Mike Looijmans
2015-01-07 9:32 ` Robert Yang [this message]
2015-01-07 10:04 ` Richard Purdie
2015-01-07 11:16 ` Burton, Ross
2015-01-07 12:49 ` Mike Looijmans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54ACFD1A.5000606@windriver.com \
--to=liezhi.yang@windriver.com \
--cc=mike.looijmans@topic.nl \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.