Beefy Boxes and Bandwidth Generously Provided by pair Networks vroom
Do you know where your variables are?
 
PerlMonks  

Module::Build reccomends build_requires

by mandog (Curate)
on Jan 05, 2009 at 00:41 UTC ( #734082=perlquestion: print w/ replies, xml ) Need Help??
mandog has asked for the wisdom of the Perl Monks concerning the following question:

I've looked at:
man Module::Build::Authoring man Module::Build::Cookbook
.but still am not sure of the best place in  Build.PL to list modules that are used only in t/*.t. In my *.t files non standard modules are guarded like:
use Test::More; # in Build.PL::build_requires eval 'use Test::Do::Funky:Chicken;' if ($@){ plan skip_all => 'Test::Funky::Chicken needed'; }else{ plan tests => 99; }

I am tending toward the recommends section.

Advice ?

UPDATE: fixed eval per ysth kind and helpful advice.

Comment on Module::Build reccomends build_requires
Select or Download Code
Re: Module::Build reccomends build_requires
by ysth (Canon) on Jan 05, 2009 at 01:11 UTC
    eval{use Test::Do::Funky:Chicken;}
    You need require or eval STRING for that. eval BLOCK compiles the block at the same time the rest of your code is compiled, and the eval only traps runtime exceptions while executing BLOCK. Since "use" takes effect at compile time, your code will die when the module isn't found.
Re: Module::Build reccomends build_requires
by Anonymous Monk on Jan 05, 2009 at 01:11 UTC
    Look again
    build_requires
    Items that are necessary for building and testing this distribution, but aren't necessary after installation. This can help users who only want to install these items temporarily. It also helps reduce the size of the CPAN dependency graph if everything isn't smooshed into requires.

      Anony Monk:

      It certainly didn't hurt to re-re-read that bit from the man page However "Necessary" is a bit relative. For example Test::Perl::Critic explicitly says it shouldn't be included in distributed tests.

      Perhaps, I'm really trying to ask what the standard way to track/document testing dependencies that are not needed/desired for installation but are very nice for development.

        Yeah, it could use a 'build_recommends' and a 'configure_recommends' section. But it sounds like even that isn't what you want, really.

        Personally, I'd say if you really don't expect people to run those tests except when in development, I'd just not put them in the Build.PL or Meta.yml: They aren't part of the user's installation. They are part of your development suite. A programmer can find them in the test code, if they need to see them. (And they'll know to look because you are skipping the tests with a good message. Right?)

        Some people even have an environment variable they check for this case, and don't even try to run the tests if it isn't there. I've never quite gotten that complicated myself...

Re: Module::Build reccomends build_requires
by xdg (Monsignor) on Jan 05, 2009 at 03:12 UTC
    I am tending toward the recommends section.

    My advice is to use the "build_requires" section for anything used in testing that isn't too obscure or hard to install. The problem with "recommends" is that it suggests things that should be installed and modules to only support testing don't need to be installed.

    That said, if you have too many obscure Test::* modules in your build_requires, you increase the chance that someone fails to build and test your module due to a dependency failure. If you guard every Test::* module with eval, then that's not a problem, but that's a lot of work.

    Personally, I use "build_requires" for just about everything and only guard with eval a handful of more obscure dependencies that don't really impact the effectiveness of testing or are platform-specific.

    You're welcome to browse my distributions for examples. Most of them use Build.PL

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://734082]
Approved by sundialsvc4
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (4)
As of 2014-04-19 20:54 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (483 votes), past polls