Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re: Module::Build reccomends build_requires

by xdg (Monsignor)
on Jan 05, 2009 at 03:12 UTC ( #734098=note: print w/replies, xml ) Need Help??


in reply to Module::Build reccomends build_requires

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.

  • Comment on Re: Module::Build reccomends build_requires

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://734098]
help
Chatterbox?
[Corion]: haukex: Aaah - I thought you were still running these tests on every machine, but you only run these as author or Devel::Cover tests
[Corion]: haukex: Yeah, I think back then I used Test::Inline, which used a pod parser that was going through some changes and I didn't want to cater for all the various versions and thus stopped testing the Pod completely
[choroba]: I usually do this with presentations
[Corion]: But now I think statically (re)generating the Pod tests is a saner approach, and likely I'll regenerate the tests either in Makefile.PL or from xt/ but have them live below t/
[choroba]: I keep the snippets in files of their own, and use a Makefile to syntax highlight them and insert them into slides, while also running them and inserting the output if required
[Corion]: choroba: Ooooh - I didn't think of that! I write my presentations as POD and if it "roughly" looks like Perl code, I should also syntax-check that...
[haukex]: Yes sorry I don't run them all the time, my POD tests are only run as author tests (and are excluded when I'm using Devel::Cover)
[Corion]: choroba: Hmm - no, I keep the snippets inline, but as my framework also has support for capturing output etc., maybe I should do the same...
[Corion]: haukex: Yes, that approach is sane, and it heals the fragility of Pod parsers in a nice way while still syntax-checking stuff
[choroba]: Unfortunately, none of it is online

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (6)
As of 2017-02-27 12:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?






    Results (385 votes). Check out past polls.