[gentoo-dev] Packages with optional test dependencies

[gentoo-dev] Packages with optional test dependencies

[Michał Górny]

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

Hello,

There are some Python packages which have a bunch of optional tests
utilizing external packages. For example, the dev-python/logilab-common
runs a few additional tests if dev-python/egenix-mx-base is installed;
if the package is not installed, it just skips those tests.

Those tests can't be really considered 'heavy' or in any way suggesting
use of an additional USE flag.

Do you believe that the ebuilds should:

a) depend on all optional test dependencies conditionally to USE=test,
   therefore always requesting the widest (and consistent) testing,

b) not depend on the optional test dependencies, resulting in less
   dependencies for most users but also a bit inconsistent test
   experience,

c) put the optional test dependencies behind an additional USE flag?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Packages with optional test dependencies

[Diego Elio Pettenò]

Go for a. The widest and more consistent the testing, the better.

Otherwise the day after tomorrow you'll get a bug from me that with
$foo installed, $bar fails tests.
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


On Sun, Jan 6, 2013 at 11:38 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Hello,
>
> There are some Python packages which have a bunch of optional tests
> utilizing external packages. For example, the dev-python/logilab-common
> runs a few additional tests if dev-python/egenix-mx-base is installed;
> if the package is not installed, it just skips those tests.
>
> Those tests can't be really considered 'heavy' or in any way suggesting
> use of an additional USE flag.
>
> Do you believe that the ebuilds should:
>
> a) depend on all optional test dependencies conditionally to USE=test,
>    therefore always requesting the widest (and consistent) testing,
>
> b) not depend on the optional test dependencies, resulting in less
>    dependencies for most users but also a bit inconsistent test
>    experience,
>
> c) put the optional test dependencies behind an additional USE flag?
>
> --
> Best regards,
> Michał Górny

Re: [gentoo-dev] Packages with optional test dependencies

[hasufell]

I agree with "a".
A problem with "b" is: the user might install one of those "optional
dependencies" later, but that will not trigger a rebuild of the other
package and another run through the test phase.
I would find "c" a bit confusing.

The most elegant way would probably be to trigger a remerge of package
a, when you want to emerge package b which is also an optional
dependency of package a (in case package a has a test phase ofc). But I
don't see a clean and easy way to do that.

On 01/06/2013 01:28 PM, Diego Elio Pettenò wrote:
> Go for a. The widest and more consistent the testing, the better.
> 
> Otherwise the day after tomorrow you'll get a bug from me that with
> $foo installed, $bar fails tests.
> Diego Elio Pettenò — Flameeyes
> flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
> 
> 
> On Sun, Jan 6, 2013 at 11:38 AM, Michał Górny <mgorny@gentoo.org> wrote:
>> Hello,
>>
>> There are some Python packages which have a bunch of optional tests
>> utilizing external packages. For example, the dev-python/logilab-common
>> runs a few additional tests if dev-python/egenix-mx-base is installed;
>> if the package is not installed, it just skips those tests.
>>
>> Those tests can't be really considered 'heavy' or in any way suggesting
>> use of an additional USE flag.
>>
>> Do you believe that the ebuilds should:
>>
>> a) depend on all optional test dependencies conditionally to USE=test,
>>    therefore always requesting the widest (and consistent) testing,
>>
>> b) not depend on the optional test dependencies, resulting in less
>>    dependencies for most users but also a bit inconsistent test
>>    experience,
>>
>> c) put the optional test dependencies behind an additional USE flag?
>>
>> --
>> Best regards,
>> Michał Górny
> 

Re: [gentoo-dev] Packages with optional test dependencies

[Diego Elio Pettenò]

I forgot to mention that (a) is what the Ruby team has been doing up
to now -- it feels a bit more cumbersome in some cases, but it's
definitely easier to spot the problems from the start than finding
them months after adding the package of the tree.

Especially if you change your mind and decide that you want to add the
dependency _after_ the package has been keyworded by half the arches
out there.
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


On Sun, Jan 6, 2013 at 1:50 PM, hasufell <hasufell@gentoo.org> wrote:
> I agree with "a".
> A problem with "b" is: the user might install one of those "optional
> dependencies" later, but that will not trigger a rebuild of the other
> package and another run through the test phase.
> I would find "c" a bit confusing.
>
> The most elegant way would probably be to trigger a remerge of package
> a, when you want to emerge package b which is also an optional
> dependency of package a (in case package a has a test phase ofc). But I
> don't see a clean and easy way to do that.
>
> On 01/06/2013 01:28 PM, Diego Elio Pettenò wrote:
>> Go for a. The widest and more consistent the testing, the better.
>>
>> Otherwise the day after tomorrow you'll get a bug from me that with
>> $foo installed, $bar fails tests.
>> Diego Elio Pettenò — Flameeyes
>> flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
>>
>>
>> On Sun, Jan 6, 2013 at 11:38 AM, Michał Górny <mgorny@gentoo.org> wrote:
>>> Hello,
>>>
>>> There are some Python packages which have a bunch of optional tests
>>> utilizing external packages. For example, the dev-python/logilab-common
>>> runs a few additional tests if dev-python/egenix-mx-base is installed;
>>> if the package is not installed, it just skips those tests.
>>>
>>> Those tests can't be really considered 'heavy' or in any way suggesting
>>> use of an additional USE flag.
>>>
>>> Do you believe that the ebuilds should:
>>>
>>> a) depend on all optional test dependencies conditionally to USE=test,
>>>    therefore always requesting the widest (and consistent) testing,
>>>
>>> b) not depend on the optional test dependencies, resulting in less
>>>    dependencies for most users but also a bit inconsistent test
>>>    experience,
>>>
>>> c) put the optional test dependencies behind an additional USE flag?
>>>
>>> --
>>> Best regards,
>>> Michał Górny
>>
>
>

Re: [gentoo-dev] Packages with optional test dependencies

[Matthew Thode]

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

On 01/06/2013 06:56 AM, Diego Elio Pettenò wrote:
> I forgot to mention that (a) is what the Ruby team has been doing up
> to now -- it feels a bit more cumbersome in some cases, but it's
> definitely easier to spot the problems from the start than finding
> them months after adding the package of the tree.
> 
> Especially if you change your mind and decide that you want to add the
> dependency _after_ the package has been keyworded by half the arches
> out there.
> Diego Elio Pettenò — Flameeyes
> flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
> 
> 
> On Sun, Jan 6, 2013 at 1:50 PM, hasufell <hasufell@gentoo.org> wrote:
>> I agree with "a".
>> A problem with "b" is: the user might install one of those "optional
>> dependencies" later, but that will not trigger a rebuild of the other
>> package and another run through the test phase.
>> I would find "c" a bit confusing.
>>
>> The most elegant way would probably be to trigger a remerge of package
>> a, when you want to emerge package b which is also an optional
>> dependency of package a (in case package a has a test phase ofc). But I
>> don't see a clean and easy way to do that.
>>
>> On 01/06/2013 01:28 PM, Diego Elio Pettenò wrote:
>>> Go for a. The widest and more consistent the testing, the better.
>>>
>>> Otherwise the day after tomorrow you'll get a bug from me that with
>>> $foo installed, $bar fails tests.
>>> Diego Elio Pettenò — Flameeyes
>>> flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
>>>
>>>
>>> On Sun, Jan 6, 2013 at 11:38 AM, Michał Górny <mgorny@gentoo.org> wrote:
>>>> Hello,
>>>>
>>>> There are some Python packages which have a bunch of optional tests
>>>> utilizing external packages. For example, the dev-python/logilab-common
>>>> runs a few additional tests if dev-python/egenix-mx-base is installed;
>>>> if the package is not installed, it just skips those tests.
>>>>
>>>> Those tests can't be really considered 'heavy' or in any way suggesting
>>>> use of an additional USE flag.
>>>>
>>>> Do you believe that the ebuilds should:
>>>>
>>>> a) depend on all optional test dependencies conditionally to USE=test,
>>>>    therefore always requesting the widest (and consistent) testing,
>>>>
>>>> b) not depend on the optional test dependencies, resulting in less
>>>>    dependencies for most users but also a bit inconsistent test
>>>>    experience,
>>>>
>>>> c) put the optional test dependencies behind an additional USE flag?
>>>>
>>>> --
>>>> Best regards,
>>>> Michał Górny
>>>
>>
>>
> 
This is what I have been doing with my python packages. ('A', that is.)

-- 
-- Matthew Thode (prometheanfire)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: Packages with optional test dependencies

[Ryan Hill]

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

On Sun, 6 Jan 2013 11:38:42 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> a) depend on all optional test dependencies conditionally to USE=test,
>    therefore always requesting the widest (and consistent) testing,

We also need to be more strict about making sure testsuites pass and fixing
them (or disabling them) if not.  Right now so many packages fail
that, as far as I can tell, the main benefit of enabling FEATURES=test is to
warm my apartment with the heat of the extra CPU cycles.


-- 
gcc-porting
toolchain, wxwidgets            learn a language baby, it's that kind of place
@ gentoo.org                   where low card is hunger and high card is taste

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]