On Mon, Oct 12, 2009 at 11:17 PM, Damyan Ivanov <d...@modsoftsys.com> wrote:
> -=| David Golden, Fri, Oct 09, 2009 at 07:45:22AM -0400 |=-
>> 07. Enhance granularity of prerequisites
>>
>> Proposal:
>>
>> Add "test_requires" distinct from "build_requires". (Adam Kennedy)
>>
>> This proposal is driven by the needs of the downstream distribution
>> packagers. At Oslo, they requested this separation to allow them to more
>> accurately package modules. I forget, however, the EXACT mechanism that
>> this change was driving downstream, and this MUST be clarified before we
>> add it. Adding a new dependency type simply because it looks like a good
>> idea isn't sufficient, we need to be absolutely sure that it does what the
>> downstream wants before we add it.
>>
>> [...]
>>
>> * Speaking from a Debian perspective, whether it is required for
>> testing or
>> for building, we include it as a Build dependency. We try to run as many
>> tests as possible (including author tests, though we prefer
>> AUTOMATED_TESTING to RELEASE_TESTING now). We would really consider
>> test_requires and build_requires equivalent. (jawnsy)
>
> Speaking as part of the group that dedicates its time on packaging
> CPAN dists for Debian, I'd say that we don't make difference between
> 'building' and 'testing' as the later is always part of the former in
> the Debian package build.
With RPMs, we don't currently have a mechanisim to differentiate
between build and test requires, either. However, the distinction is
a valuable one, I think... We're currently looking at ways to enable
running tests post-build/install, for QA purposes... This would help
in that matter.
I can also see situations where the set of test requirements isn't a
superset of the build requirements; that is, we might need something
to build but not to test.
I guess another way to put it would be "is test just a part of the
build process, or is test a process of its own?"
> Separating the requirements for tests that aren't supposed to be run
> during normal package building would be useful. Something like
> "author_test_requires".
>
> In general, we try to run as much tests as possible, unles they are
> things like Critic tests, which can break with nre releases of
> Perl-Critic.
>
> Currently we try to fine-tune using environment variables, and this
> works as long as authors use them consistently. Having a separate
> dependency declaration for fargile tests may hopefuly help standartize
> the usage of environment variables to turn them on.
That's essentially our policy in Fedora, too -- any tests not
explicitly marked as author tests, that test the functionality of the
code rather than subjective quality (kwalitee, critic, etc) must be
run. (e.g. Test::Pod tests must be run, but running
Test:::Pod::Coverage tests isn't mandatory) I don't believe author
test requirements should be included in any test_requires, as my
understanding of a test_requires is something the user will require to
run tests. I can't think of any package including author test
requirements in test_requires, so I think it's safe to say that's the
common understanding of the existing spec tag.
Author tests either skipped unless $ENV{TEST_AUTHOR} or segregated out
(e.g. in xt/ rather than t/) shouldn't be in test_requires. An
author_test_requires may help keep authors in sync for situations
where one dist is maintained by multiple authors (Moose, Catalyst, etc
come to mind)... But the question of if that's in scope for this
effort is one best answered by someone else.
One key I would like to see added would be something along the lines
of "optional_test_requires" or "test_recommends", etc. There are
many, many packages that skip tests if some other non-related module
isn't already installed (e.g. DBIx::Class and
DateTime::Format::MySQL). It would be _very_ useful to know what
additional modules are needed to enable so-called optional tests of
this nature... As per policy we're almost certainly going to have to
BR them for the build, having ready metadata to assist with this will
save human cycles.
-Chris
--
Chris Weyl
Ex astris, scientia
