How do you decide to use a module from CPAN or not?

[trs80]

I have used more modules then I can remember over the years
to get various projects done and I have been curious
how others decide if they will use a particular module.
I am very impatient so I take the code that is in the
synopsis and modify it slightly to fit what I am doing
and if that runs fine and I understand it, I explore a
little further. If a module doesn't make sense right off
the bat I scrape it. I know I have lost out on some very
good modules since I wasn't willing to invest the time to
learn.

What do other monks do?

[stephen]

I have a few criteria I use. In no particular order:
• Does it do exactly what I want it to do? It can be the greatest module in the world, and yet still not be useful to me. If I'm trying to do signal analysis on my MP3s, LWP::Agent won't help me much.
• What is the state of the code? If it's a mission-critical application, I want released, well-tested code. If it's experimental, it's reasonable to use some more cutting-edge, alpha code.
• How well-tested is it? For critical applications, I'd want to take a look at the build tests and see if what I'm trying to do with the code is tested at build-time. This will save hours of agony when upgrading.
• How well-documented is the code? Documentation is important in its own right. Also, good documentation is the sign of a conscientious author and well-tested code. (Although not an infallible one.)
• How conscientious is the author? An active mailing list and a helpful maintainer can make up for a number of module-related sins.

However, if the module fails any of these tests, my first impulse isn't (or at least shouldn't be) to shrug my shoulders and rewrite from scratch. Instead, if the fundamental design of the module is good, and it merely suffers from some missing features, testing gaps, or bad documentation, the best alternative is to spend at least an hour trying to fix the problem yourself, then send the patch to the author. (Much of this is situationally dependent-- if the project is due in 45 minutes... well then I've already messed up.)

I won't claim to have followed this philosophy completely in the past, since to be honest I hadn't thought about it much. I will follow it in the future, though. :)

stephen

[kal]

I admit to being extremely shallow, and looking first and last at the API. Not only am I interested in whether or not the API makes sense to me, I also favour modules that can be programmed in my favourite coding style. Everyone has their own style, and sometimes if there is a selection of different modules doing similar things I try to find one which best matches me - it seems to be a good way of achieving karmic balance in your programming :-)

Another thing I sometimes think about is how portable the module is. I have a bias towards pure Perl modules - I try to avoid those with C/C++/whatever components where possible. So, a pure Perl implementation may gain favour over a 'wrapper' implementation, since it reduces the dependencies in the code.

But, I think the most important thing is that it has to feel 'right' in the code and fit in with the program - if it causes you to re-write sections of your program, think about why you've chosen it. Maybe it's given you a different view on the problem, and leading you to better ways. On the other hand, maybe it's not.

[belg4mit]

I mentioned this somewhere vaguely, I myself:
• 0 I rely upon the module name or the *.readme, and secondarily the README or pod if using .*search.cpan.org
• 1 Is it supposed to do what I want? skip to 3
• 2 Is it related to what I want? (Could I rethink my strategy to make use of it)
• 3 Does it work? skip to 5
• 4 Can I make it work, or cajole the author into doing so?
• 5 I use it.
• * And finally, is it just plain cool and likely to be something I'll use if it's laying around? (I'm a packrat, there's a reason I have 300k of bookmarks even after pulling out most of the software
I frankly don't care about the API, as I much as I dislike OO if it works I'll take what I can get, same goes for support (excluding step 4) and maturity.

--
perl -pe "s/\b;([st])/'\1/mg"