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)