Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Friday March 16, 2007
12:07 AM

Module::Install 0.66_02 - tests_recursive and more requires

[ #32707 ]

I've uploaded a new dev release of Module::Install to the CPAN.

This test version contains some new features that scratch a few itches of mine.

tests_recursive

The tests_recursive command tells M:I that you want to search for test scripts recursively.

By default, tests_recursive means tests_recursive('t') and will search under that directory for any directories containing test scripts.

So if you have...

t/foo.t
t/bar.t
t/subdir/baz.t
... then calling tests_recursive is effectively the same as

tests( 't/*.t t/subdir/*.t' );

I can't be entirely sure, but this should work everywhere. I'm a little unsure about mac though, hence the dev release.

Module::Install's own Makefile.PL uses tests_recursive to test it, so when you make test the new release, you should see a test script in a subdirectory get tested (it just runs a single pass test).

Also in this new version I've added the new generation of more detailed requires commands. These add a bit more granularity to the dependencies.

configure_requires module, version;
build_requires module, version;
test_requires module, version;
install_requires module, version;

The normal "requires" command remains unchanged, and is taken to mean "runtime requires".

In the current codebase, test_requires and install_requires are just aliases to build_requires, which will work as per normal. You might want to change from build_requires to test_requires, but it's not essential.

More interesting is the configure_requires command.

At the moment, this is a null implementation and does nothing.

In the near future, this will write the dependencies out to the upcoming configure_requires entry in META.yml.

configure_requires information will ONLY be available via META.yml, meaning they can't be platform-sensitive or be determined programatically at install time.

HOWEVER, in exchange for this limitation, CPAN clients will be expected detect these dependencies from the META.yml and install them BEFORE the CPAN client runs the Makefile.PL or Build.PL.

Amoungst other things, this will finally allow Module::Build dependencies to bootstrap properly, as the Module::Build used to create a package can automagically add itself as a configure_requires dependency, ensuring that the configuration module itself is installed on the user's computer.

It will also allow things like configure-time plugins and other similar functionality.

By adding these to Module::Install now, you can start to prepare for the new enhancements now, and once support is added to META.yml and the CPAN clients, some future upgrade of Module::Install will cause them to just start working.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • What is difference between 'install_requires' and 'configure_requires'? Isn't 'configure_requires', 'test_requires' and 'requires' enough to represent all possible dependencies?

    • No. The kinds of dependencies you list are determined dynamically by executing Makefile.PL or Build.PL. The meaning of configure_requires is that this is what’s required to successfully run Makefile.PL or Build.PL in the first place. In other words, without the configure_requires dependency installed you cannot even determine the rest of them.