On Tue, Oct 13, 2009 at 4:19 PM, Chris Weyl <[email protected]> wrote:
> 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?"
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.
>> Separating the requirements for tests that aren't supposed to be run
>> during normal package building would be useful. Something like
>> "author_test_requires".
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.
> One key I would like to see added would be something along the lines
> of "optional_test_requires" or "test_recommends", etc. There are
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
