CMSP 07. Enhance granularity of prerequisites

* David Golden [2009-10-09T07:45:22]
Agreed. Also suggest (08. Extensibly Group Prereqs) as related and useful.

+1

Graham.

+1

D

Agree on both points.

+1 in conjunction with proposal 08.

Steffen

Yes please. Currently I put things required for testing into
build_requires, but I feel bad about doing it, because testing really is
a distinct job from building. Consumers of META information should be
expected to merge phase-specific requirements in whatever way is suitable
for their workflow; we can't reliably predict what that workflow will be.

-zefram

-=| David Golden, Fri, Oct 09, 2009 at 07:45:22AM -0400 |=-
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.

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.

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?"
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

It's complicated. In Makefile.PL, with just PREREQ_PM, *all* such
prerequisites are satisfied after the Makefile.PL is run -- before
"make" or "make test" -- and all prerequisites are installed if an
installation is requested.

With Build.PL, with separate "requires" and "build_requires", both
sets of prerequisites are satisfied after Build.PL -- before "Build"
and "Build test" -- but while "requires" are installed,
"build_requires" may or may not be, depending on settings in
CPAN/PLUS.

The argument I've heard for "test_requires" is that someone might want
to install test_requires so they can run tests after installation, but
that build_requires would not be needed post installation. I'm not
sure if that's a real case we should consider or not.
Some have argued for a "release_requires" or "developer_requires" --
things that an author would want installed during packaging, but that
wouldn't be needed by end users.
If we move to a two-level scheme, we could have something like this:

prereq => {
runtime => {
requires => {
JSON => 2.00,
},
recommends => {
JSON::XS => 0,
},
},
build => {
requires => {
ExtUtils::CBuilder => 0,
},
},
test => {
recommends => {
Test::Deep => 0,
},
},
};

In practice, there may never really be "test/requires", but it would be
theoretically possible.

-- David

-=| Chris Weyl, Tue, Oct 13, 2009 at 01:19:00PM -0700 |=-
Agreed. Sorry for making my comments sound like I am against
separation.
Agreed. We use to watch the build log and add build-dependencies.
Having some machine-aid to this would certainly be helpful.