On Mon, Dec 18, 2017 at 3:17 PM, Derek Straka <[email protected]> wrote: > 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.
I can respect this approach. I will put the RDEPENDS back and send out a V2. As for the overall approach being applied to all python recipes, my opinion still stands that this is such a small subset that we are devoting time better spent elsewhere to service the few. Mark > > -Derek > > On Mon, Dec 18, 2017 at 11:56 AM, Mark Asselstine < > [email protected]> wrote: > >> On Mon, Dec 18, 2017 at 11:37 AM, Alexander Kanavin >> <[email protected]> wrote: >> > On 12/18/2017 06:15 PM, Mark Asselstine wrote: >> >> >> >> On Mon, Dec 18, 2017 at 10:36 AM, Christopher Larson <[email protected] >> > >> >> wrote: >> >>> >> >>> All our python recipes should be explicitly listing the python module >> >>> packages they require. No python module recipes should be depending on >> >>> python-modules or python3-modules, but explicitly what they require. >> >> >> >> >> >> This is a giant PITA for little gain in my opinion. The typical python >> >> 'vehicles' to define dependencies, things like setup.py, requires.txt, >> >> requirements.txt..., never bother to list stdlibs. These are standard >> >> libs that are just expected to be there. If a system is being >> >> installed with only select python modules it will behave differently >> >> than python found on any other system violating the rule of least >> >> surprise. On top of this most of these modules are ~40K in size and >> >> there are roughly 60 in the stdlib so the size gain in installing a >> >> few vs. all of them is extremely negligible. All of this seems to add >> >> way more work and churn that outweighs any real benefit. >> > >> > >> > I tend to agree with this. Add also the situation that the yocto project >> > needs to upgrade oe-core to python 3.6 as soon as possible, and to 3.7 >> soon >> > after, no one has enough time to do this rather non-trivial job, and I'm >> > beginning to wonder if the best way out is to remove the module splitting >> > altogether, and write a clean, simple and maintainable python3 recipe >> from >> > scratch with minimal amount of custom patching and hopefully no >> write-only >> > hacks. >> > >> > Alex >> >> Thanks Alex for the support. To get a better idea as to what the size >> delta is I took the installed sizes from a rootfs logfile and the >> total size for all modules (python2.7) is 6.5M python-misc is almost >> 2M of this and python-codecs contributing over 0.5M. The savings will >> never be the full 6.5M as there will always be python-lang and some >> other modules needed. There was a time where 32M restrictions existed >> are some systems but are we really seeing devices with these >> restrictions any more? what about exploring not shipping the pyc >> files? I would much rather see this than imposing so much work and >> churn for very little gain. Anyways, maybe this isn't the best forum >> for this and it should be brought up to the architecture group. >> >> Mark >> >> > >> > -- >> > _______________________________________________ >> > Openembedded-devel mailing list >> > [email protected] >> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel >> -- >> _______________________________________________ >> Openembedded-devel mailing list >> [email protected] >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel >> > -- > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
