Beefy Boxes and Bandwidth Generously Provided by pair Networks Joe
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

How to pick a CPAN module

by dragonchild (Archbishop)
on Oct 31, 2008 at 20:16 UTC ( #720773=perlmeditation: print w/ replies, xml ) Need Help??

CPAN is the single biggest strength of Perl. Without the (literally) 10,000 man-years of work available for free, Perl would be nothing more than a semi-interesting footnote in the early history of the web. Other than some neat text-processing facilities, Perl doesn't have much going for it in terms of being a good business workhorse language. Other than the CPAN.

But, CPAN's greatest strengths (a million solutions for every problem, anyone can just upload stuff) are also its greatest weaknesses. How do you find a CPAN module that does what you need, let alone the right CPAN module?

  • Use CPAN's search feature (http://search.cpan.org). You may have to use a number of different synonyms to find modules.
  • Don't restrict yourself to the first page of results. I always click the 100 on the right-hand side to see 100/page vs. the default 10.
  • You will have to look at several modules to find a few good candidates. I generally read between 4-7 to get a sense of what's going on.
  • Take a very close look at the version number and the last-uploaded date for the distributions. You're looking for the following:
    • A last-updated date within the past year. Anything older than that is probably not being actively maintained anymore. While this isn't a death knell, it is a strike against this module.
    • If it's 0.01, 0.02, or 0.03, it's probably not what you want. Remember, CPAN is often the place where active authors will collaborate. Kind of like a global SVN. :-)
    • If you have any questions, don't hesitate to email the author using the address on the author's CPAN page. If that bounces, don't use the module unless you're willing to maintain it.
  • Install your top 2-3 choices and play with them. At this point, you're going for functionality, not speed. If a couple tests fail, force the installation. Just because the author screwed up a testcase with your platform doesn't mean it won't work for you. You probably won't use that feature anyways. Even if you do, it's usually just a minor edit of the source.

Don't forget to ask your friends, IRC channels, or here for advice. But, most importantly, email the author if you have questions about the fitness or suitability of a given distribution for a given task. We want to hear from you. We're certainly not getting paid for this work. Knowing our code is in active use is one of the very few rewards for being a CPAN author.


My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on How to pick a CPAN module
Re: How to pick a CPAN module
by hossman (Prior) on Oct 31, 2008 at 22:48 UTC

    Suggestions for additional evaluation criteria (most don't even require installation -- just links from search.cpan.org)

    • What does the version history look like? have there been multiple versions or just one?
    • Does it have any reviews? are the comments positive?
    • When browsing the source tree, are there many tests?
    • What do the test result stats look like? have people with your architecture and perl version gotten test failures?
    • Is it in the phalanx? what do it's coverage stats look like?
    • Are there robust perldocs?
    • What dependencies does it have?
    • What is the percentage of unresolved bugs on rt.cpan.org? (don't consider it a negative if there are no bugs at all, it might not be used)
    • Does it have a mailing list with public archives? is there a healthy amount of traffic on that list?
      Is it in the phalanx?

      I think this probably the most important point. A quality label for modules would be VERY helpful as ratings obviously don't work. I don't know much about the phalanx project. But a project where authors and users can submit modules easily and get objective advice from experienced developers (maybe bored during coffee break) would be great. The review process should be very simple, maybe with a standardized scoring table. Once the module passes the quality requirements, it should be accepted in phalanx or something similar and labeled in CPAN accordingly.

Re: How to pick a CPAN module
by shmem (Canon) on Nov 01, 2008 at 00:13 UTC
    If it's 0.01, 0.02, or 0.03, it's probably not what you want.

    Maybe, maybe not. A module author might scrutinize his work as best as he can before even daring to publish. A version 0.01 doesn't necessarily mean a unproved or buggy version; and if the module "works for me[tm]" for the module author, he might, lacking feedback, not update at all. The version number is no quality metric at all.

    My module AutoReloader is an example of what's stated above, it is version 0.0.2, sits around on CPAN with that version for over a year - but maybe it's just superfluous, not called for at all, and hence of no value.

    I don't know, since there's no feedback other than in this thread.

Re: How to pick a CPAN module
by Jenda (Abbot) on Nov 01, 2008 at 00:55 UTC

    Don't look at the date of the last update. Look at the date of the last open issue for the module. Maybe the module doesn't need any update.

    Besides ... what was the last time you really went through this exercise? I find that I get to know about modules from here or other mailing lists. Last time I did need to find a module for something I did not need before, it was for SSH File Transfer Protocol. I spent more time with Google and PerlMonks' Super Search than with the CPAN search and the module documentation. You are probably looking for a module to solve some problem, what about starting by looking at what did others use and got suggested for that problem?

      Support Denmark! Defend the free world!

      Well that issue seems to have (dis)solved itself, somehow . . .
      The journey to Saturn

      allan :)
Re: How to pick a CPAN module
by toolic (Chancellor) on Nov 01, 2008 at 16:21 UTC
    The "recommended CPAN modules" site has helped me make informed decisions:

    http://www.perlfoundation.org/perl5/index.cgi?recommended_cpan_modules

    I also follow the "Discussion Forum" link on each module's page to see if there is a forum, and if so, what level of activity it has.

    Performing a Super Search here at the Monastery can also be quite revealing:

    • Some CPAN authors provide continual support for their modules here.
    • The Monks are not shy about voicing their opinions (good and bad) about modules, highlighting strengths and weaknesses.
    • There are a plethora of real-life examples and usage scenarios for some modules.
Re: How to pick a CPAN module
by tsee (Curate) on Nov 02, 2008 at 09:47 UTC

    While I generally agree with your post and criteria, there's one that most certainly isn't right:

    Looking at the version number is not going to help much. You have to factor in the complexity of the module you're looking at, the experience of the author, etc. Similarly, just because there hasn't been a release in a year, the module isn't necessarily broken. It may just be stable and proven (and I don't mean "biologically stable").

    Let me suggest a modified metric:

    • Take a very close look at the release history and request tracker of the module as well as the release history of its maintainer.
      • Has the maintainer uploaded any distributions (of this module or another) to CPAN within the past six months? If not, he may be unavailable to fix bugs you might find.
      • Does the author/maintainer typically do many releases of a module or just one or two? Specifically if you're looking at something really ingenious or complicated, there must have been bugs to start with. The quality of maintenance is naturally related to how long it kept the attention of the author.
      • How much time passed on average between a bug report in the request tracker and a reply from the maintainer?
      • If you have questions, check the module documentation for contact info. Only if no explicit contact information can be found in the documentation should you try the mail address of the maintainer's search.cpan.org address.

    Do not underestimate the last point. The average quality of support requests for PAR that goes to the mailing list is better than that of those which end up in my inbox regularly. Why? The former at least glanced at the docs. So for many authors, this may be a red herring and you start out on the wrong foot.

    Cheers,
    Steffen

Re: How to pick a CPAN module
by duff (Vicar) on Nov 03, 2008 at 04:23 UTC

    I wonder if it would be worthwhile to come up with a heuristic that takes into account the CPAN rating, the version number, the last upload, the number of uploads, the number of downloads, the number of modules that depend on this module, etc. to give people a better sense of "is this the module I should use?" CPAN ratings was supposed to be something like that originally, but I think it doesn't quite tell you enough about the module.

    If someone did an algorithm similar to Google's PageRank where instead of links you use module dependencies, that seems like it would be useful.

      This is a wonderful idea! ++

      But i see some problems. Some authors have their modules broken into several smaller ones and have dependencies among each other. Others have monolithic modules. With dependencies raising the module rank, the latter would be handicapped, and I don't think they should.

      Also, in the former case, where one big (and more important) module depends on many smaller ones, the smaller would be favored.

      use strict; use warnings; print "Just Another Perl Hacker\n";
Re: How to pick a CPAN module
by DrHyde (Prior) on Nov 03, 2008 at 11:51 UTC

    Looking at the last-updated date and the version number is not very useful.

    Looking at the date means that a module that you'd consider to be a good candidate today will magically stop being a good candidate in a few years time. This is nonsense, of course. A module not being updated could just mean that no bugs have been reported. The latest release of Class::CanBeA is three years old, because three years ago is the last time anyone reported a bug or asked for a feature.

    And going by the version number is equally silly. Version numbers don't mean a thing. Wanna know why Devel::CheckLib is only version 0.5? It's because I'm a perfectionist and don't consider it to be complete until it works on VMS. But as a user, you almost certainly don't care about VMS. And if you *do* care about VMS, then there's nothing else that does the job anyway (and patches welcome!). Then there's Scalar::Properties currently (and for the last year) at version 0.13. It has gone through many releases and is damned useful, despite its measly little version number.

      I pointed out that those are metrics, not absolutes. Class::CanBeA may be a perfectly good module. That it hasn't been touched in 3 years simply means that I will look at it harder than if there were more recent releases? Why? Because I've been burned by abandonware.

      As for version numbers, I didn't talk about the magical 1.0 - I talked about 0.01, 0.02, and 0.03. I also talked about those in terms of the number of releases period that the module has had. If Scalar::Properties has had many releases, then it doesn't qualify, does it? :-)

      Though, I'm curious - what's the difference between Scalar::Properties and autobox?


      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
        Scalar::Properties is two years older. Other than that, I'd have to read the autobox doco :-)
Re: How to pick a CPAN module
by IlyaM (Parson) on Nov 07, 2008 at 15:57 UTC
    As I use Debian as my work desktop I quite often use
    apt-cache search keyword | grep perl
    as a first step when looking for Perl module for certain task. For those who are not familiar with Debian - apt-cache is just a tool to search for Debian packages by keywords. It actually works often quite well because if Perl package was repackaged as Debian package there is a very good change it is an old well proven module which is being used by many other people. Only if I don't like Debian package search results I go shopping on CPAN.

    --
    Ilya Martynov

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://720773]
Approved by Corion
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (10)
As of 2014-04-21 12:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (494 votes), past polls