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

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

[Alexander Kanavin]

On 12/18/2017 06:15 PM, Mark Asselstine wrote:
> On Mon, Dec 18, 2017 at 10:36 AM, Christopher Larson <kergoth@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

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

[Mark Asselstine]

On Mon, Dec 18, 2017 at 11:37 AM, Alexander Kanavin
<alexander.kanavin@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@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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Derek Straka]

[-- Attachment #1: Type: text/plain, Size: 3857 bytes --]

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.

-Derek

On Mon, Dec 18, 2017 at 11:56 AM, Mark Asselstine <
mark.asselstine@windriver.com> wrote:

> On Mon, Dec 18, 2017 at 11:37 AM, Alexander Kanavin
> <alexander.kanavin@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@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@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>

[-- Attachment #2: Type: text/html, Size: 5145 bytes --]

Re: [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@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@windriver.com> wrote:
>
>> On Mon, Dec 18, 2017 at 11:37 AM, Alexander Kanavin
>> <alexander.kanavin@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@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@lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>> --
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[Derek Straka]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

I also need to look at the UPSTREAM_CHECK_URI for this recipe since it
isn't finding the latest version and telling me to update the package.

On Mon, Dec 18, 2017 at 4:02 PM, S. Lockwood-Childs <sjl@vctlabs.com> wrote:

> On Mon, Dec 18, 2017 at 03:17:25PM -0500, Derek Straka 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.
>
> Me too -- some of my projects still use NAND for rootfs, where space is
> tight and
> ability to split out python modules is very useful. Thus it is not an
> unused
> feature, though many projects have SD/eMMC for rootfs and those ones
> generally
> will not care about it.
>

[-- Attachment #2: Type: text/html, Size: 1824 bytes --]

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

[Mark Asselstine]

On Monday, December 18, 2017 4:07:44 PM EST Derek Straka wrote:
> I also need to look at the UPSTREAM_CHECK_URI for this recipe since it
> isn't finding the latest version and telling me to update the package.

Odd. Let me know how it goes. If it is easier for you to make the changes 
locally and complete the merge go for it.

Mark

> 
> On Mon, Dec 18, 2017 at 4:02 PM, S. Lockwood-Childs <sjl@vctlabs.com> wrote:
> > On Mon, Dec 18, 2017 at 03:17:25PM -0500, Derek Straka 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.
> > 
> > Me too -- some of my projects still use NAND for rootfs, where space is
> > tight and
> > ability to split out python modules is very useful. Thus it is not an
> > unused
> > feature, though many projects have SD/eMMC for rootfs and those ones
> > generally
> > will not care about it.

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

[Derek Straka]

[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]

Go ahead and do a v2, it was more of a reminder for me.

On Mon, Dec 18, 2017 at 4:26 PM, Mark Asselstine <
mark.asselstine@windriver.com> wrote:

> On Monday, December 18, 2017 4:07:44 PM EST Derek Straka wrote:
> > I also need to look at the UPSTREAM_CHECK_URI for this recipe since it
> > isn't finding the latest version and telling me to update the package.
>
> Odd. Let me know how it goes. If it is easier for you to make the changes
> locally and complete the merge go for it.
>
> Mark
>
> >
> > On Mon, Dec 18, 2017 at 4:02 PM, S. Lockwood-Childs <sjl@vctlabs.com>
> wrote:
> > > On Mon, Dec 18, 2017 at 03:17:25PM -0500, Derek Straka 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.
> > >
> > > Me too -- some of my projects still use NAND for rootfs, where space is
> > > tight and
> > > ability to split out python modules is very useful. Thus it is not an
> > > unused
> > > feature, though many projects have SD/eMMC for rootfs and those ones
> > > generally
> > > will not care about it.
>
>

[-- Attachment #2: Type: text/html, Size: 2904 bytes --]

splitting python's standard library

[Alexander Kanavin]

On 12/18/2017 11:02 PM, S. Lockwood-Childs wrote:
> On Mon, Dec 18, 2017 at 03:17:25PM -0500, Derek Straka 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.
> 
> Me too -- some of my projects still use NAND for rootfs, where space is tight and
> ability to split out python modules is very useful. Thus it is not an unused
> feature, though many projects have SD/eMMC for rootfs and those ones generally
> will not care about it.

This configuration can be supported by making a custom python3-modules 
package that whitelists precisely the needed files. But it shouldn't be 
imposed on everyone else - it's a significant burden to maintain the 
dependencies in every single python package, and keep the splitting 
working correctly in core python as well.

So I'd like to drop that - do keep in mind that very few people maintain 
oe-core (as opposed to sending occasional drive-by patches to fix 
specific issues raised in product development), and the headcount keeps 
getting smaller.

Alex

Re: splitting python's standard library

[Derek Straka]

[-- Attachment #1: Type: text/plain, Size: 2386 bytes --]

Well, I've been able to do it just fine for the majority of packages in
meta-python by myself.  Since I contribute the majority of the patches and
maintain the layer, I want this capability maintained in meta-python.  If
you plan on removing that functionality in oe-core, I'd like to have the
opportunity to maintain the python recipes there as well rather than have a
feature unilaterally removed.  I don't consider it a burden and my
customers find it valuable to split things out.

On Dec 19, 2017 2:55 AM, "Alexander Kanavin" <
alexander.kanavin@linux.intel.com> wrote:

On 12/18/2017 11:02 PM, S. Lockwood-Childs wrote:

> On Mon, Dec 18, 2017 at 03:17:25PM -0500, Derek Straka 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.
>>
>
> Me too -- some of my projects still use NAND for rootfs, where space is
> tight and
> ability to split out python modules is very useful. Thus it is not an
> unused
> feature, though many projects have SD/eMMC for rootfs and those ones
> generally
> will not care about it.
>

This configuration can be supported by making a custom python3-modules
package that whitelists precisely the needed files. But it shouldn't be
imposed on everyone else - it's a significant burden to maintain the
dependencies in every single python package, and keep the splitting working
correctly in core python as well.

So I'd like to drop that - do keep in mind that very few people maintain
oe-core (as opposed to sending occasional drive-by patches to fix specific
issues raised in product development), and the headcount keeps getting
smaller.

Alex

[-- Attachment #2: Type: text/html, Size: 2988 bytes --]

Re: splitting python's standard library

[Alexander Kanavin]

On 12/19/2017 02:31 PM, Derek Straka wrote:
> Well, I've been able to do it just fine for the majority of packages in 
> meta-python by myself.  Since I contribute the majority of the patches 
> and maintain the layer, I want this capability maintained in 
> meta-python.  If you plan on removing that functionality in oe-core, I'd 
> like to have the opportunity to maintain the python recipes there as 
> well rather than have a feature unilaterally removed.  I don't consider 
> it a burden and my customers find it valuable to split things out.

If you're able to take over the maintenance of oe-core's python 
packages, then that's great and much appreciated! I'll send a patch that 
assigns them to you in a moment.

Alex

Re: splitting python's standard library

[Derek Straka]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

Cool.  Works for me.  Thanks.

-Derek

On Tue, Dec 19, 2017 at 8:12 AM, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:

> On 12/19/2017 02:31 PM, Derek Straka wrote:
>
>> Well, I've been able to do it just fine for the majority of packages in
>> meta-python by myself.  Since I contribute the majority of the patches and
>> maintain the layer, I want this capability maintained in meta-python.  If
>> you plan on removing that functionality in oe-core, I'd like to have the
>> opportunity to maintain the python recipes there as well rather than have a
>> feature unilaterally removed.  I don't consider it a burden and my
>> customers find it valuable to split things out.
>>
>
> If you're able to take over the maintenance of oe-core's python packages,
> then that's great and much appreciated! I'll send a patch that assigns them
> to you in a moment.
>
> Alex
>

[-- Attachment #2: Type: text/html, Size: 1376 bytes --]

Re: [oe] splitting python's standard library

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

On 19 December 2017 at 13:23, Derek Straka <derek@asterius.io> wrote:

> Cool.  Works for me.  Thanks.
>

There's an epic patch on the list which I'm reviewing right now that
drastically changes how the core Python library is packaged.  If you'd like
to have a look, the almost-final (my bandaid fixes need to be squashed) is
at poky-contrib:ross/py.

Ross

[-- Attachment #2: Type: text/html, Size: 707 bytes --]

Re: [oe] splitting python's standard library

[Derek Straka]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

Thanks for the heads up.  I'll pull the changeset into my testing branch
and touch up all the meta-python recipes to remove the now non-existent
packages.

On Tue, Dec 19, 2017 at 8:43 AM, Burton, Ross <ross.burton@intel.com> wrote:

> On 19 December 2017 at 13:23, Derek Straka <derek@asterius.io> wrote:
>
>> Cool.  Works for me.  Thanks.
>>
>
> There's an epic patch on the list which I'm reviewing right now that
> drastically changes how the core Python library is packaged.  If you'd like
> to have a look, the almost-final (my bandaid fixes need to be squashed) is
> at poky-contrib:ross/py.
>
> Ross
>

[-- Attachment #2: Type: text/html, Size: 1343 bytes --]

Re: [oe] splitting python's standard library

[Derek Straka]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

Let me know when this is ready to get merged into master-next.  I have a
patchset on my github for all the python recipes in meta-oe that need
updating based on the deprecated python{3} packages.  I can submit it to
the ML at that point.  Thanks.

-Derek

On Tue, Dec 19, 2017 at 9:02 AM, Derek Straka <derek@asterius.io> wrote:

> Thanks for the heads up.  I'll pull the changeset into my testing branch
> and touch up all the meta-python recipes to remove the now non-existent
> packages.
>
> On Tue, Dec 19, 2017 at 8:43 AM, Burton, Ross <ross.burton@intel.com>
> wrote:
>
>> On 19 December 2017 at 13:23, Derek Straka <derek@asterius.io> wrote:
>>
>>> Cool.  Works for me.  Thanks.
>>>
>>
>> There's an epic patch on the list which I'm reviewing right now that
>> drastically changes how the core Python library is packaged.  If you'd like
>> to have a look, the almost-final (my bandaid fixes need to be squashed) is
>> at poky-contrib:ross/py.
>>
>> Ross
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2044 bytes --]