Python 2 and Python 3 module recipes

Python 2 and Python 3 module recipes

[Dominic Sacré]

Hi,

I'm trying to build a Python 3 application which depends on some modules
that are already packaged in OE for Python 2, but not for Python 3.
Since OE currently has virtually no Python 3 module recipes, this makes
me wonder what the best approach to create these recipes would be.

In most cases, I could just copy a Python 2 recipe, change the name from
"python-foo" to "python3-foo", and replace "inherit distutils" with
"inherit distutils3". However that would create a lot of duplication,
and might turn into a maintenance nightmare.

Do you have a suggestion what the right course of action would be? Move
most of the recipes' content to .inc files that can then be included by
both Python 2 and Python 3 recipes? Or maybe create a .bbclass that
would build both versions from the same recipe?
Is there any functionality already in place that would simplify this task?


Dominic

Re: Python 2 and Python 3 module recipes

[Khem Raj]

On Sat, Aug 15, 2015 at 5:26 PM, Dominic Sacré <dominic.sacre@gmx.de> wrote:
> Hi,
>
> I'm trying to build a Python 3 application which depends on some modules
> that are already packaged in OE for Python 2, but not for Python 3.
> Since OE currently has virtually no Python 3 module recipes, this makes
> me wonder what the best approach to create these recipes would be.
>
> In most cases, I could just copy a Python 2 recipe, change the name from
> "python-foo" to "python3-foo", and replace "inherit distutils" with
> "inherit distutils3". However that would create a lot of duplication,
> and might turn into a maintenance nightmare.
>
> Do you have a suggestion what the right course of action would be? Move
> most of the recipes' content to .inc files that can then be included by
> both Python 2 and Python 3 recipes? Or maybe create a .bbclass that
> would build both versions from the same recipe?
> Is there any functionality already in place that would simplify this task?
>

bbclassextend comes to mind, but then its not a core thing, secondly
python2 is not going away soon so we will have to have them coexist.
Best is to encapsulate in .inc files and then have 1 liner recipe
files, that wont be as bad to maintain.

>
> Dominic
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: Python 2 and Python 3 module recipes

[Dominic Sacré]

On 2015-08-16 02:40, Khem Raj wrote:
> On Sat, Aug 15, 2015 at 5:26 PM, Dominic Sacré <dominic.sacre@gmx.de> wrote:
>> I'm trying to build a Python 3 application which depends on some modules
>> that are already packaged in OE for Python 2, but not for Python 3.
>> Since OE currently has virtually no Python 3 module recipes, this makes
>> me wonder what the best approach to create these recipes would be.
>>
>> In most cases, I could just copy a Python 2 recipe, change the name from
>> "python-foo" to "python3-foo", and replace "inherit distutils" with
>> "inherit distutils3". However that would create a lot of duplication,
>> and might turn into a maintenance nightmare.
>>
>> Do you have a suggestion what the right course of action would be? Move
>> most of the recipes' content to .inc files that can then be included by
>> both Python 2 and Python 3 recipes? Or maybe create a .bbclass that
>> would build both versions from the same recipe?
>> Is there any functionality already in place that would simplify this task?
> 
> bbclassextend comes to mind, but then its not a core thing, secondly
> python2 is not going away soon so we will have to have them coexist.
> Best is to encapsulate in .inc files and then have 1 liner recipe
> files, that wont be as bad to maintain.

Ok, .inc files are certainly the most straightforward option. It might
get a little messy if at some point the majority of packages come in
Python 2 and Python 3 variants, but I suppose that could take a while.

Should PV be part of the .inc filename? It would make sense if things
like SRCREV or tarball checksums are set in the .inc files, but it would
also mean that we'd have the same version number in five different
places (two .bb filenames, one .inc filename, two includes).


Dominic