<div dir="ltr">I have several customers who have optimized for space and would like to see the capability maintained unless core removes the ability to split python packages out. They also remove the *.py files in favor of *.pyo files (via a custom packaging mechanism). I have automated tests that go through the module importing on each of the meta-python packages to ensure it works on minimal python installations. When other contributors don't do provide that functionality, I either catch it when I do package update or when it breaks for one of my customers. I'm fine if you don't want to perform the checks yourself and it breaks my use case with missing dependencies, but I would prefer that you don't remove the dependencies that are currently in place. Thanks.<div><br></div><div>-Derek</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 18, 2017 at 11:56 AM, Mark Asselstine <span dir="ltr"><<a href="mailto:mark.asselstine@windriver.com" target="_blank">mark.asselstine@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Dec 18, 2017 at 11:37 AM, Alexander Kanavin<br>
<<a href="mailto:alexander.kanavin@linux.intel.com">alexander.kanavin@linux.<wbr>intel.com</a>> wrote:<br>
> On 12/18/2017 06:15 PM, Mark Asselstine wrote:<br>
>><br>
>> On Mon, Dec 18, 2017 at 10:36 AM, Christopher Larson <<a href="mailto:kergoth@gmail.com">kergoth@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> All our python recipes should be explicitly listing the python module<br>
>>> packages they require. No python module recipes should be depending on<br>
>>> python-modules or python3-modules, but explicitly what they require.<br>
>><br>
>><br>
>> This is a giant PITA for little gain in my opinion. The typical python<br>
>> 'vehicles' to define dependencies, things like setup.py, requires.txt,<br>
>> requirements.txt..., never bother to list stdlibs. These are standard<br>
>> libs that are just expected to be there. If a system is being<br>
>> installed with only select python modules it will behave differently<br>
>> than python found on any other system violating the rule of least<br>
>> surprise. On top of this most of these modules are ~40K in size and<br>
>> there are roughly 60 in the stdlib so the size gain in installing a<br>
>> few vs. all of them is extremely negligible. All of this seems to add<br>
>> way more work and churn that outweighs any real benefit.<br>
><br>
><br>
> I tend to agree with this. Add also the situation that the yocto project<br>
> needs to upgrade oe-core to python 3.6 as soon as possible, and to 3.7 soon<br>
> after, no one has enough time to do this rather non-trivial job, and I'm<br>
> beginning to wonder if the best way out is to remove the module splitting<br>
> altogether, and write a clean, simple and maintainable python3 recipe from<br>
> scratch with minimal amount of custom patching and hopefully no write-only<br>
> hacks.<br>
><br>
> Alex<br>
<br>
</div></div>Thanks Alex for the support. To get a better idea as to what the size<br>
delta is I took the installed sizes from a rootfs logfile and the<br>
total size for all modules (python2.7) is 6.5M python-misc is almost<br>
2M of this and python-codecs contributing over 0.5M. The savings will<br>
never be the full 6.5M as there will always be python-lang and some<br>
other modules needed. There was a time where 32M restrictions existed<br>
are some systems but are we really seeing devices with these<br>
restrictions any more? what about exploring not shipping the pyc<br>
files? I would much rather see this than imposing so much work and<br>
churn for very little gain. Anyways, maybe this isn't the best forum<br>
for this and it should be brought up to the architecture group.<br>
<span class="HOEnZb"><font color="#888888"><br>
Mark<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> --<br>
> ______________________________<wbr>_________________<br>
> Openembedded-devel mailing list<br>
> <a href="mailto:Openembedded-devel@lists.openembedded.org">Openembedded-devel@lists.<wbr>openembedded.org</a><br>
> <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-devel" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>devel</a><br>
--<br>
______________________________<wbr>_________________<br>
Openembedded-devel mailing list<br>
<a href="mailto:Openembedded-devel@lists.openembedded.org">Openembedded-devel@lists.<wbr>openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-devel" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>devel</a><br>
</div></div></blockquote></div><br></div>