You might be interested in How does one choose among modules?

Kyle

Thank you for posting that link. It is very useful and cites the problem perfectly.

I searched for CPAN here and got the CPAN node and tried 'start CPAN' only to find mostly writeups on the mechanics of using CPAN rather than advice on the decision process of which module to use.

I don't think I would have found that node for quite a while.

I found it by going to Super Search and entering 'CPAN' for title text, then scrolled down to almost the bottom to click "Don't include Replies". and clicked "Search". That got me a list of root nodes with "CPAN" in the title. At that point, I just scanned down the list until I saw what I was looking for. I had the advantage of knowing it was there and the disadvantage of forgetting how long ago it was (I had to look back farther than I thought).

currently use version numbering, activity, and ratings to help me choose. What about you

Additionally: Open Tickets in RT, and interface.

It's always a good sign if I know how to use the most important functions of a module after reading the first five to ten lines of the synopsis.

For example I looked into Data::Validate::Email, and the Synopsis is very convincing to me.

Other good signs are comparisons to other modules in the POD ("there are 15 other modules for exactly this job. This is why I wrote the 16th")

I can't give you advise on this particular decision, though.

Many good observations above!

Now, one that has not yet been made in this thread:

You can "validate" the form of an email address using a module; to actually "validate" the address itself, you have to check whether it exists.

This is why you'll find some/many sites with a registration option that handle the process like this:

User fills in and submits the form

Site sends a "please confirm" mail to the address supplied (with or without some sort of confirmation string and a reply-to: address used specifically for the purpose).

If the recipient responds (sometimes, within a specified length of time), site processes the reply and then (and only then) adds the new user to the list of valid emails/members/users.

For what it's worth, here's the process that I use for selecting modules:

• Write a list of requirements roughly in order of importance.
• Draw a line between the "must have" items and the ones I could live without.
• Develop a list of candidate modules via methods discussed by others in this thread.
• Read the the Description and Synopsis for each candidate and briefly scan the rest of the POD. Modules that are poorly documented or clearly do not meet the "must have" requirements are removed from consideration.

  The Description section will often tell you all you need to know about the documentation. If it's a well articulated description of the module's intended use and capability, the rest of documentation is usually well written. If it's terse, unclear or verbose you can generally expect more of the same. The synopsis should clearly show what the API looks like.

• From here on the selection process varies, but I have a requirements list to guide me and a reasonably well documented selection of modules to choose from.

What constitutes a valid email address hasn't changed in a long time, so an old module that did the job well might be perfectly usable today.

I go by popularity. I find that's the best way. (Even if the module came out a month ago, if it is very popular, it cannot be too bad).

Oh, and please do respond with the level of satisfaction using the module you end up using.

I go by popularity. I find that's the best way. (Even if the module came out a month ago, if it is very popular, it cannot be too bad).

Don't go judging something by popularity, or you'll end up preferring PHP over Perl ;-)

I prefer one well informed and well phrased opinion any time over ten people who just tell me "it's great".

I use Linux, although Windows is more popular. I use fvwm2 as my window manager, although others are far more popular. I'm helping the Perl 6 developers, although Python 3000 (or whatever its name is) gets much more positive press. I prefer pen & paper RPGs over MMORPG, although the latter are more popular.

I don't care if something is important unless I know why it's popular, and know that the same reasons might appeal to me.

Oh lawdy lawd, you are right! I guess I should have said, well, what you said. :P

Oh, and depsite me being oh-so-judging, if I do not the popular thing, I'll switch. So hah.

And for the record, I prefer Perl, use linux, and do not even like mmorpg's. ;)

<(^.^-<) <(-^.^<) <(-^.^-)> (>^.^-)> (>-^.^)>

I currently use version numbering, activity, and ratings to help me choose. What about you?

The first thing I look for is good documentation. FWICT, poor docs often portend other inadequacies.

I have been faced with the problem of choosing the 'right' module before and am curious to know how people select modules to use.

1. Search CPAN
2. narrow my selection down by reading the synopsis
3. and then depending on how big the library is I:
• read the module's source code
• unpack the distro and add my own .t files to the test directory

trwww

I find cpan ratings is becoming more useful e.g.

though when faced with no differentation I tend to install and briefly try out all of the approaches ... this is pretty time consuming; its a function of how important the feature is.

My top tip is to have a peek around the t directory, run the tests, investigate the test code .... more often then not there is a correlation of the perceived quality of tests and me choosing the module.

Lastly, I am pragmatic with modules that have a large number of dependencies ... there are lots of good ones out there, but these need more investigation before I adopt them into my toolbox.

You really can't judge a module by its version number or by how often it gets updated. What does it tell you that Data::Compare is now at version 1.19? Nothing. If you look at the release history on search.cpan.org you'll see that it went straight from 0.17 to 1.18. If you look at the changes in that release, you'll see that there were only a few very minor changes, far less significant than those between 0.05 and 0.06. You'll also see that it spent two years as version 0.13, two and a bit years at 0.02, and two years at 0.01.

And if those two year gaps weren't enough to convince you that activity isn't necessarily a sign of a good module, look at Statistics::SerialCorrelation (not updated for 4.5 years) or Tie::Scalar::Decay (not updated for 7 years).

The best things to look at IMO are:

• other programmers' recommendations, so ask your local perl mongers
• CPAN-testers results
• portability
• dependencies
• the rather confusing advanced search on rt.cpan.org, which *may* let you see how quickly reported bugs get fixed. Although that won't include bugs reported directly to the author by email.

Some of those - especially portability and dependencies - are somewhat subjective, of course. It's my opinion, for example, that a module that works on lots of different platforms is higher quality than one that does the same job but only on a few platforms - I think it shows either that the author has better coding practices, or that he cares more. And a module with lots of dependencies, while it does demonstrate admirable code re-use and avoids reinventing wheels badly, could also be harder to install and is subject to bugs that may be introduced later in its dependencies especially if those dependencies have poor test coverage.