[OE-core] [oe] [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22)

[Mark Asselstine]

On Mon, Dec 18, 2017 at 3:17 PM, Derek Straka <derek at asterius.io> 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 <
> mark.asselstine at windriver.com> wrote:
>
>> On Mon, Dec 18, 2017 at 11:37 AM, Alexander Kanavin
>> <alexander.kanavin at linux.intel.com> wrote:
>> > On 12/18/2017 06:15 PM, Mark Asselstine wrote:
>> >>
>> >> On Mon, Dec 18, 2017 at 10:36 AM, Christopher Larson <kergoth at gmail.com
>> >
>> >> 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
>> > Openembedded-devel at lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>> --
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel