[Buildroot] [RFC] python: select vs depends on

[Buildroot] [RFC] python: select vs depends on

[Thomas De Schampheleire]

Hi,

Currently, we have a dual strategy with respect to packages that have
optional Python support: alsa-lib uses 'depends on python' for its
'python support' option, while ola uses 'select python' for its
'python bindings'.

The alsa-lib line has been changed from 'select' to 'depends on' with
commit 45c8d2037866248818a52f0d0f7d7a6d467b016f, and description:
"As discussed on the list."

The relevant thread seems to be:
http://lists.busybox.net/pipermail/buildroot/2009-January/024938.html
where Peter says:

----
 ulf> +config BR2_PACKAGE_ALSA_LIB_PYTHON
 ulf> + bool "Python support for alsa-lib"
 ulf> + depends on BR2_PACKAGE_ALSA_LIB
 ulf> + select BR2_PACKAGE_PYTHON

It would probably be good to add a 'default BR2_PACKAGE_PYTHON' line,
so it defaults to enabled if you have python support, and false
otherwise.

Alternatively it should depend on BR2_PACKAGE_PYTHON and just be
default y, as it's probably pretty unlikely someone wants python
support in alsa without having python enabled in the first place.

The 2nd option seems cleanest to me, what do you think?
----

The reasoning makes sense, but one could also reason: if someone
enables python support in alsa, he agrees that the python package is
automatically selected.

So there are two ways to look at this, and I'd like to make a decision
on this. There are three different situations:

- python modules (typically named python-foo): here the current
strategy is to use 'depends on', and this is followed by all such
packages. For me, this is perfectly sane, and is (IMO) not open for
discussion.
Note: in fact, all these modules are in one 'if python' block in
package/Config.in, and I have prepared a patch to remove the redundant
'depends on'.

- for 'normal' packages that need python for there normal behavior, we
typically use 'select python'. In this case, the user may not be aware
of the python dependency, and requiring him/her to first enable python
is not logical. I think this reasoning is sane too.

- for 'normal' packages that do not require python, but have optional
python support (as is the case for ola and alsa-lib), I have no strong
preference. Whichever is preferred by the community is ok with me, as
long as we keep one guideline for this case.


Based on the outcome of the above discussion, I would like to update
the manual and line up the packages that do not conform.

Thanks for your input!
(and Merry Christmas)

Best regards,
Thomas

[Buildroot] [RFC] python: select vs depends on

[Yann E. MORIN]

On 2013-12-24 18:14 +0100, Thomas De Schampheleire spake thusly:
> Currently, we have a dual strategy with respect to packages that have
> optional Python support: alsa-lib uses 'depends on python' for its
> 'python support' option, while ola uses 'select python' for its
> 'python bindings'.
[--SNIP--]
> - python modules (typically named python-foo): here the current
> strategy is to use 'depends on', and this is followed by all such
> packages. For me, this is perfectly sane, and is (IMO) not open for
> discussion.
> Note: in fact, all these modules are in one 'if python' block in
> package/Config.in, and I have prepared a patch to remove the redundant
> 'depends on'.
> 
> - for 'normal' packages that need python for there normal behavior, we
> typically use 'select python'. In this case, the user may not be aware
> of the python dependency, and requiring him/her to first enable python
> is not logical. I think this reasoning is sane too.
> 
> - for 'normal' packages that do not require python, but have optional
> python support (as is the case for ola and alsa-lib), I have no strong
> preference. Whichever is preferred by the community is ok with me, as
> long as we keep one guideline for this case.

Or what about just removing the 'depends on' or 'select' for packages
sub-options, and just add the dependencies and options in the .mk files,
such as:

---8<--- alsa-lib.mk ---8<---
ifeq ($(or $(BR2_PACKAGE_PYTHON),$(BR2_PACKAGE_PYTHON3)),y)
ALSA_LIB_CONF_OPT += \
        --with-pythonlibs=-lpython$(PYTHON_VERSION_MAJOR) \
        --with-pythonincludes=$(STAGING_DIR)/usr/include/python$(PYTHON_VERSION_MAJOR)
ALSA_LIB_CFLAGS+=-I$(STAGING_DIR)/usr/include/python$(PYTHON_VERSION_MAJOR)
ALSA_LIB_DEPENDENCIES = python
else
ALSA_LIB_CONF_OPT += --disable-python
endif
---8<--- alsa-lib.mk ---8<---

And so on for other packages...

We already ave this behaviour in other packages:
  - bind adds features if openssl or libxml2 are selected
  - libvncserver, with libgcrypt, libjpeg, or openssl
  - libpcap, with libusb or libnl
  - and so on. countless times...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [RFC] python: select vs depends on

[Thomas De Schampheleire]

Hi Yann,

On Tue, Dec 24, 2013 at 6:28 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> On 2013-12-24 18:14 +0100, Thomas De Schampheleire spake thusly:
>> Currently, we have a dual strategy with respect to packages that have
>> optional Python support: alsa-lib uses 'depends on python' for its
>> 'python support' option, while ola uses 'select python' for its
>> 'python bindings'.
> [--SNIP--]
>> - python modules (typically named python-foo): here the current
>> strategy is to use 'depends on', and this is followed by all such
>> packages. For me, this is perfectly sane, and is (IMO) not open for
>> discussion.
>> Note: in fact, all these modules are in one 'if python' block in
>> package/Config.in, and I have prepared a patch to remove the redundant
>> 'depends on'.
>>
>> - for 'normal' packages that need python for there normal behavior, we
>> typically use 'select python'. In this case, the user may not be aware
>> of the python dependency, and requiring him/her to first enable python
>> is not logical. I think this reasoning is sane too.
>>
>> - for 'normal' packages that do not require python, but have optional
>> python support (as is the case for ola and alsa-lib), I have no strong
>> preference. Whichever is preferred by the community is ok with me, as
>> long as we keep one guideline for this case.
>
> Or what about just removing the 'depends on' or 'select' for packages
> sub-options, and just add the dependencies and options in the .mk files,
> such as:
>
> ---8<--- alsa-lib.mk ---8<---
> ifeq ($(or $(BR2_PACKAGE_PYTHON),$(BR2_PACKAGE_PYTHON3)),y)
> ALSA_LIB_CONF_OPT += \
>         --with-pythonlibs=-lpython$(PYTHON_VERSION_MAJOR) \
>         --with-pythonincludes=$(STAGING_DIR)/usr/include/python$(PYTHON_VERSION_MAJOR)
> ALSA_LIB_CFLAGS+=-I$(STAGING_DIR)/usr/include/python$(PYTHON_VERSION_MAJOR)
> ALSA_LIB_DEPENDENCIES = python
> else
> ALSA_LIB_CONF_OPT += --disable-python
> endif
> ---8<--- alsa-lib.mk ---8<---
>
> And so on for other packages...
>
> We already ave this behaviour in other packages:
>   - bind adds features if openssl or libxml2 are selected
>   - libvncserver, with libgcrypt, libjpeg, or openssl
>   - libpcap, with libusb or libnl
>   - and so on. countless times...

To me that sounds fine. So for optional support of other packages, we
automatically enable it when the dependency is present, from the .mk
file, and the Config.in does not contain an explicit option.

Is this accepted by other contributors as well?

Best regards,
Thomas

[Buildroot] [RFC] python: select vs depends on

[Arnout Vandecappelle]

On 25/12/13 19:42, Thomas De Schampheleire wrote:
> Hi Yann,
>
> On Tue, Dec 24, 2013 at 6:28 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>> On 2013-12-24 18:14 +0100, Thomas De Schampheleire spake thusly:
>>> Currently, we have a dual strategy with respect to packages that have
>>> optional Python support: alsa-lib uses 'depends on python' for its
>>> 'python support' option, while ola uses 'select python' for its
>>> 'python bindings'.
>> [--SNIP--]
>>> - python modules (typically named python-foo): here the current
>>> strategy is to use 'depends on', and this is followed by all such
>>> packages. For me, this is perfectly sane, and is (IMO) not open for
>>> discussion.
>>> Note: in fact, all these modules are in one 'if python' block in
>>> package/Config.in, and I have prepared a patch to remove the redundant
>>> 'depends on'.
>>>
>>> - for 'normal' packages that need python for there normal behavior, we
>>> typically use 'select python'. In this case, the user may not be aware
>>> of the python dependency, and requiring him/her to first enable python
>>> is not logical. I think this reasoning is sane too.
>>>
>>> - for 'normal' packages that do not require python, but have optional
>>> python support (as is the case for ola and alsa-lib), I have no strong
>>> preference. Whichever is preferred by the community is ok with me, as
>>> long as we keep one guideline for this case.
>>
>> Or what about just removing the 'depends on' or 'select' for packages
>> sub-options, and just add the dependencies and options in the .mk files,
>> such as:
>>
>> ---8<--- alsa-lib.mk ---8<---
>> ifeq ($(or $(BR2_PACKAGE_PYTHON),$(BR2_PACKAGE_PYTHON3)),y)
>> ALSA_LIB_CONF_OPT += \
>>          --with-pythonlibs=-lpython$(PYTHON_VERSION_MAJOR) \
>>          --with-pythonincludes=$(STAGING_DIR)/usr/include/python$(PYTHON_VERSION_MAJOR)
>> ALSA_LIB_CFLAGS+=-I$(STAGING_DIR)/usr/include/python$(PYTHON_VERSION_MAJOR)
>> ALSA_LIB_DEPENDENCIES = python
>> else
>> ALSA_LIB_CONF_OPT += --disable-python
>> endif
>> ---8<--- alsa-lib.mk ---8<---
>>
>> And so on for other packages...
>>
>> We already ave this behaviour in other packages:
>>    - bind adds features if openssl or libxml2 are selected
>>    - libvncserver, with libgcrypt, libjpeg, or openssl
>>    - libpcap, with libusb or libnl
>>    - and so on. countless times...
>
> To me that sounds fine. So for optional support of other packages, we
> automatically enable it when the dependency is present, from the .mk
> file, and the Config.in does not contain an explicit option.
>
> Is this accepted by other contributors as well?

  I agree with the principle that scripting language bindings are enabled 
automatically when the scripting language is selected.

  There could be exceptions when the bindings add a lot of bloat, like 
e.g. Riverbank's python bindings of Qt4 (but these are anyway a separate 
package).


  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [RFC] python: select vs depends on

[Clayton Shotwell]

> From: Arnout Vandecappelle <arnout@mind.be>
> To: Thomas De Schampheleire <patrickdepinguin@gmail.com>, "Yann E. 
> MORIN" <yann.morin.1998@free.fr>
> Cc: buildroot <buildroot@busybox.net>
> Date: 01/09/2014 01:46 AM
> Subject: Re: [Buildroot] [RFC] python: select vs depends on
> Sent by: buildroot-bounces at busybox.net
> 
> On 25/12/13 19:42, Thomas De Schampheleire wrote:
> > Hi Yann,
> >
> > On Tue, Dec 24, 2013 at 6:28 PM, Yann E. MORIN <yann.morin.
> 1998 at free.fr> wrote:
> >> On 2013-12-24 18:14 +0100, Thomas De Schampheleire spake thusly:
> >>> Currently, we have a dual strategy with respect to packages that 
have
> >>> optional Python support: alsa-lib uses 'depends on python' for its
> >>> 'python support' option, while ola uses 'select python' for its
> >>> 'python bindings'.
> >> [--SNIP--]
> >>> - python modules (typically named python-foo): here the current
> >>> strategy is to use 'depends on', and this is followed by all such
> >>> packages. For me, this is perfectly sane, and is (IMO) not open for
> >>> discussion.
> >>> Note: in fact, all these modules are in one 'if python' block in
> >>> package/Config.in, and I have prepared a patch to remove the 
redundant
> >>> 'depends on'.
> >>>
> >>> - for 'normal' packages that need python for there normal behavior, 
we
> >>> typically use 'select python'. In this case, the user may not be 
aware
> >>> of the python dependency, and requiring him/her to first enable 
python
> >>> is not logical. I think this reasoning is sane too.
> >>>
> >>> - for 'normal' packages that do not require python, but have 
optional
> >>> python support (as is the case for ola and alsa-lib), I have no 
strong
> >>> preference. Whichever is preferred by the community is ok with me, 
as
> >>> long as we keep one guideline for this case.
> >>
> >> Or what about just removing the 'depends on' or 'select' for packages
> >> sub-options, and just add the dependencies and options in the .mk 
files,
> >> such as:
> >>
> >> ---8<--- alsa-lib.mk ---8<---
> >> ifeq ($(or $(BR2_PACKAGE_PYTHON),$(BR2_PACKAGE_PYTHON3)),y)
> >> ALSA_LIB_CONF_OPT += \
> >>          --with-pythonlibs=-lpython$(PYTHON_VERSION_MAJOR) \
> >>          --with-pythonincludes=$(STAGING_DIR)/usr/include/python$
> (PYTHON_VERSION_MAJOR)
> >> 
ALSA_LIB_CFLAGS+=-I$(STAGING_DIR)/usr/include/python$(PYTHON_VERSION_MAJOR)
> >> ALSA_LIB_DEPENDENCIES = python
> >> else
> >> ALSA_LIB_CONF_OPT += --disable-python
> >> endif
> >> ---8<--- alsa-lib.mk ---8<---
> >>
> >> And so on for other packages...
> >>
> >> We already ave this behaviour in other packages:
> >>    - bind adds features if openssl or libxml2 are selected
> >>    - libvncserver, with libgcrypt, libjpeg, or openssl
> >>    - libpcap, with libusb or libnl
> >>    - and so on. countless times...
> >
> > To me that sounds fine. So for optional support of other packages, we
> > automatically enable it when the dependency is present, from the .mk
> > file, and the Config.in does not contain an explicit option.
> >
> > Is this accepted by other contributors as well?
> 
>   I agree with the principle that scripting language bindings are 
enabled 
> automatically when the scripting language is selected.
> 
>   There could be exceptions when the bindings add a lot of bloat, like 
> e.g. Riverbank's python bindings of Qt4 (but these are anyway a separate 

> package).

For what it's worth, I added in menuconfig options to all of the SELinux 
packages to specifically enable the Python bindings.  When that option is 
enabled, Python is selected.  Doing it this was way chosen after several 
conversations with Thomas P. about the issue.

Thanks,
Clayton

Clayton Shotwell
Software Engineer
clshotwe at rockwellcollins.com
www.rockwellcollins.com 

[Buildroot] [RFC] python: select vs depends on

[Thomas De Schampheleire]

On Thu, Jan 9, 2014 at 3:21 PM, Clayton Shotwell
<clshotwe@rockwellcollins.com> wrote:
[..]

>
> For what it's worth, I added in menuconfig options to all of the SELinux
> packages to specifically enable the Python bindings.  When that option is
> enabled, Python is selected.  Doing it this was way chosen after several
> conversations with Thomas P. about the issue.
>

Ah, interesting!
So Thomas, what do you have to say for yourself? ;-)

[Buildroot] [RFC] python: select vs depends on

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Fri, 10 Jan 2014 07:44:50 +0100, Thomas De Schampheleire wrote:

> > For what it's worth, I added in menuconfig options to all of the SELinux
> > packages to specifically enable the Python bindings.  When that option is
> > enabled, Python is selected.  Doing it this was way chosen after several
> > conversations with Thomas P. about the issue.
> 
> Ah, interesting!
> So Thomas, what do you have to say for yourself? ;-)

In the SELinux libraries, the Python stuff is only used when you want
to *debug* SELinux (i.e tune your SELinux policy). Therefore, it is
unlikely that you will need all these SELinux Python bindings on a
final production system. Therefore, it didn't seem appropriate to
enable them automatically when Python is enabled: you may well want to
have Python *and* SELinux on a system, but necessarily have all the
Python bindings of these SELinux libraries, since those are only needed
for debugging purposes.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com