amarquis has asked for the wisdom of the Perl Monks concerning the following question:

I was working on a response to File::Find::prune problems, when I saw grinder's response:

"If you're starting out with File::Find, then the best advice I can give you is... don't. It is old and bletcherous and there's no need to use it for new work."

So off I went to look at File::Find::Rule, which he'd suggested. And you know what? It is a really neat, and I'll probably be using it over File::Find from now on.

But I don't really want to talk about File::Find, I want to talk about CPAN. I'm always finding modules via PerlMonks that I like better than what I'm using (which I got via my own CPAN searching). Part of the reason for that is I tend to go with the first-fit rather than the best-fit. Why? Because my CPAN ritual is sort of a pain in the rear:

  1. Initial search, either by category or Kobe's search to find a candidate.
  2. Skim the documentation,
  3. Still looking good? Great, look through the reviews. Not a lot of reviews? No reviews? Okay, go check the bug tracker, and search on Perlmonks. Maybe CPAN testers, annocpan, and cpanforum too.
  4. Do I want to go back to step one? No, just install it.

So my question is, is there any better metric or search methodology that will get me quality/popluarity information about a module faster? How do you go about finding solutions on CPAN?

  • Comment on Using CPAN effectively; Finding the best fit module.

Replies are listed 'Best First'.
Re: Using CPAN effectively; Finding the best fit module.
by NetWallah (Canon) on Mar 28, 2008 at 15:50 UTC
    A very similar question was asked recently - please see the question and responses in "we need a list".

    In particular, Your Mother directs us to Recommended CPAN Modules, in the perl5 wiki.

         "As you get older three things happen. The first is your memory goes, and I can't remember the other two... " - Sir Norman Wisdom

      This one has a better title (and this *is* important). Repeating what I answered at the other thread - we should start putting 'recommended alternatives' into CPAN rating comments.

        This is a very good idea.

        The issue with the reviews is that there are not enough of them. With many (most?) modules it isn't just a matter of "not enough to determine quality" - there aren't any!

        CPAN won't see a great volume of reviews without serious thinking and work going into the review system. Which is why I like your idea: it is simple, and gets the job done. If even a few reviews that said "This module is a 4/5, it does X well but if you want to do Y too you should look at module Z" it would help me track down my best-fit module faster.

        I think I'll start adding reviews like this when I find a set of good, related solutions.

      Apparently spx2 and I had the same reaction to his thread, as it spawned the same question for each of us. I composed the post, ran off to a meeting, and posted it when I get back, only to find his thread already posted. :(

Re: Using CPAN effectively; Finding the best fit module.
by kyle (Abbot) on Mar 28, 2008 at 16:07 UTC
Re: Using CPAN effectively; Finding the best fit module.
by dragonchild (Archbishop) on Mar 28, 2008 at 16:47 UTC
    I do threee things to find modules.
    1. As neat things come up in the CPAN nodelet, I check them out. 10% of the time, this works for me.
    2. If I need something, I ask mst or someone else in #catalyst or #dbix-class. 90% of the time, this works for me.
    3. If those two don't work, I write it, then release it.

    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?
Re: Using CPAN effectively; Finding the best fit module.
by salva (Canon) on Mar 29, 2008 at 12:41 UTC
    I think that one of the problems with CPAN is that new modules have a big disadvantage in respect to older ones.

    Older modules have the best namespaces and are referenced in forums, magazines, books, etc. so people searching for something will find them first. Even PerlMonks is very conservative in that regard, because people recommends what it knows and use and for the same reasons, they tend to know old modules better.

    That happens with File::Find, google for perl find and the first entries point to it, both "Learning Perl" and "The Perl Cookbook" talk about it, it's even on the core!

Re: Using CPAN effectively; Finding the best fit module.
by stu42j (Sexton) on Mar 31, 2008 at 18:30 UTC
    One method that I use is to look at programs and other modules that I already use and see what modules they depend on.

    For example, I really like ack and it uses File::Next for finding files so last time I needed a file finding module, I gave File::Next a try. In this case, they are both by the same author which is another good way for finding modules.

Re: Using CPAN effectively; Finding the best fit module.
by eserte (Deacon) on Apr 02, 2008 at 21:33 UTC