What Perl module would you be lost without?

+9  A: 

My first choice would be strict but since that is more of a pragma (rather than a module), I'd probably say DBI.

Brian Phillips

How about the Perl module which goes through this site and removes questions from people asking questions just trying to get reputation?

Mark Schill
How about something that removed answers from people trying to score points for moral indignation?
Get reputation how, exactly? The question has one upvote so far. Doesn’t look like a very effective karma whoring move, now does it.
Aristotle Pagaltzis
The article that brought me here, from one of the founders, specifically encourages stuff like this, including polls and trying to "score" reputation: I'm just sore cause I asked the same question today and got smacked down. :)
This reminds me of Slashdot, where everyone is so obsessed with karma that most discussions ignore the topic so they can bitch about moderation. It all means nothing, if you're doing anything at all here just to increase that meaningless number next to your name you're far too easily amused. But whatever floats your boat I guess, I'm here to learn and to teach where I can, I could give a damn about my meaningless number.
+3  A: 

DBI - probably over 80% of the things I do with Perl require a database.

+1  A: 

CGI and DBI hard to choose between them but most things I do have these somewhere near the bottom of the stack.

+1  A: 

While DBI is the first thing that came to mind, I can work around it w/o having it. I would be lost without win32::API on the sad occasions I've had to write code that used it.

+26  A: 

If we're allowed built-ins, then Data::Dumper.

When I'm debugging, I want to be able to see what that data structure looks like...

+5  A: 
+2  A: 

Just one choice? That's so hard. I'd have to say Josh Pritikin's 'Event'. It is the backbone of every non-trivial Perl program I write.

+3  A: 

When I'm writing network I almost always use POE. It's one of the most amazing networking libraries that I know. Of course saying that POE is just a networking library sells it short. It's among other things an amazing mainloop as well. Just a few days ago I wrote a music player with it, which contains a combination of Gstreamer and a networking protocol, all in the same program.

Peter Stuifzand
+2  A: 

It's probably DBI. I use LWP heavily but I'm guessing that I could more easily replace it than DBI.

William Jens
+10  A: -- because it's my gateway to all the great libraries that people have already written to make my job easier.

You should take a look at It's like, but better.
It's only sometimes better. has built in support for Module::Build, but CPANPLUS requires an additional module, CPANPLUS::Dist::Build, to work correctly. And without it, it invents a Makefile.PL, causing problems. (Note, I have commit bits to both projects. They each have pros and cons.)
+15  A: 

Moose. Gets rid of the cruft involved in implementing Perl OO, and allows me to just get the hell on and code in a manner my peers can follow and maintain.

That's cool, I didn't know about Moose. I will definitely make use of that.
+2  A: 

DB_File. I like most of those answers, but I use DB_File the most.

+2  A: 

DBI and Data::Dumper

Everything I do is either driven by a database or ends up in a database, so DBI is a must.

Data::Dumper is just magic for debugging.

Matthew Watson
+4  A: 

FileHandle. Lots of Perl scripts I write deal with files and although I could do without this module, it's neater to pass around files as objects.

I just use lexical filehandles (open my $out '>', 'somewhere'). It seems to work ok.
+4  A: 

First one that came to mind is DBI, but then I remembered that I mostly use DBIx::Class these days and I could live with either of them. Then I thought of Data::Dumper but I really like Data::Dump better.

Finally, it hit me: this is a trick question. With the wealth of CPAN modules and TMTOWTDI, there should be no module you can't live without.

... and to answer the question about which module I like best, I'd say Catalyst, because I've learned more from it than from any other Perl module or framework.

+3  A: 

I'm dabbling a lot in XML, so I'd have to say XML::LibXML. There are other excellent XML modules out there (XML::Twig and the pure-Perl-when-all-else-fails XML::XPath), but XML::LibXML is the primary one I keep using over and over again.

+2  A: 

I would be lost without many Perl modules. Test::More,, Template-Toolkit, String::ShellQuote, DBI,, XML::RSS/XML::Feed, Module::Build, Term::ANSIColor, Exception::CLass, Exporter, Class::Accessor, XML::LibXML, Getopt::Long (still didn't take the Moose path), CPANPLUS::Dist::Mdv, File::Path, HTML::Parser and friends and many of my own.

Shlomi Fish
+5  A: 

Can't live without Text::CSV_XS for parsing and generating line-oriented structured data.

+5  A: 
  • Perl::Critic, to avoid bad coding practices within the Perl idiom.
  • Perl::Tidy, to keep my code consistently formatted.
  • Getopt::Euclid, to keep my --help documentation consistent with my POD documentation.
  • CPAN and CPANPLUS, to keep my perl installation current.
  • YAML and Config::Simple, to standardize configuration files.
+3  A: 

Damian Conway's Smart::Comments, and I use YAML for a bit of modeling (see, specifically the fast YAML::Syck.

In addition, I have my own module (not on CPAN) Test::Setup which is just an easy importer for Test::More and Benchmark and Perl6::Say (on 5.8).

Oh, and not to mention a bunch of core modules: Scalar::Util, List::Util (and List::MoreUtils), Symbol, and of course Carp.

If you want all the `Util` modules, just grap `Util::Any`.
Ryan Thompson
+8  A: 

For modules in the core of Perl itself:

  • Data::Dumper - It's a debugging tool and a serialization format
  • IO::Handle (and thus IO::File, IO::Socket, etc.) - OO interface to IO, and transparent treatment of files, sockets, etc. without all that "\*" noise
  • AutoLoader - Don't load all 20 subroutines in your library if you only need 1 of them

From CPAN:

  • LWP - 80% or more of what I do is web-related
  • XML::LibXML - ...and about 80% is XML-related, with a not-insignificant overlap
  • Net::Twitter - My Twitter CPAN-bot needs this, and I don't have the free time to write it myself, so...
  • DBD::SQLite - (and by implication, DBI of course) A single-file, self-contained RDBMS with transactions, triggers, et al is full of win

Of course, I'd argue that probably the most critical/useful is the CPAN module itself...

+8  A: 


I'd like to say DBI and DBD::Oracle, but they're such a pain to get working (under cygwyn) that they're almost non-functional. That's a special feature of cygwin I guess, 'cause ActiveState works peachy.

+13  A: 

There are many modules whose absence would make my Perl programmer life quite a lot less comfortable. If I were to enumerate those, the result would be virtually identical to rjray’s list.

However, there is only one single module that I use in every program and without which I truly would be lost: strict. Seriously. It has happened to me in some cases, like when I started writing code on the command line and then put into a file to evolve it into a proper program, or when I got involved with someone else’s code, that I missed that crucial use strict; line at the top of the file. Every time without fail, I would make a stupid typo that would cost me hours of scratching my head over apparent logic bugs, that in the end turned out to be nothing but a trivial spelling mistake in some identifier.

I think it’s easy to forget just how much time and mental effort strict saves on an ongoing basis, simply because as conscientious programmers we’re so incredibly used to it. (Of course, ultimately that is just as it should be.)

Aristotle Pagaltzis
+3  A: 

DBI for sure...that one should just be a given. Outside of that, Data::Dumper

+5  A: 

'strict' and 'warnings' have probably saved me more head-scratching time than anything else.

Honorable mentions (in no particular order) to DBI, XML::LibXML, Moose, HTML::Parser, Path::Class, Log::Log4perl, Getopt::Long, File::Find::Rule, DateTime, Test::More, WWW::Mechanize and Data::Dumper. I can't even imagine how how bad my code would be without these (and many others), let alone how much longer it would have taken to write.

+3  A: 

I do a lot of date arithmetic at $work, and my first (and only) port of call is Date::Calc. Yes, the DateTime project is the way to go these days, but since I've committed most of the API to memory, and the problem domain can be addressed in a purely procedural manner, it seems to work out just fine.

Getopt::Long is another module who's API I know off by heart. For command-line argument parsing, it's hard to beat.

Mail::Sendmail is my favourite e-mail sending module for batch processes to phone home when things go wrong.

I use Net::LDAP for hacking on LDAP directories, although I hate the interface. That said, I've been using it for years and I cannot think of an interface that would be an improvement. The problem domain is complex.

+2  A: 

DateTime and family, although there are a number of implementation decisions DateTime made that I think are poor, and I prefer some of the interface of Time::Piece + Time::Seconds (formerly Time::Object; I liked the previous name better, too).

+3  A: 

Along with many listed here, for general coding I would also include:

For package testing, I would also not do without:

+2  A: 

IO:All - It makes everything easy and uniform (Files, DBs, Sockets, etc)

The only problem with IO::All is that even when tied, they still are not complete drop-in replacements for filehandles or `IO::Handle` objects. In particular, some BioPerl methods that accept filehandles will not accept tied IO::All objects.
Ryan Thompson
+2  A: 

Everything I write has tests, so Test::Builder without which most of the other testing modules would not exist.

+1  A: 
  • Carp
  • LWP::*
  • DBI
  • Data::Dumper
  • forks
+1  A: 

While this module is by no means a universal cure-all, over the past two years if Nagios::Plugin had not existed I would assuredly have had to implement it myself, and probably not as well.


CGI. I rarely write a perl script without it. But that's just the nature of most of my perl scripts.

Kurt W. Leucht
+6  A: 

I tend to use Path::Class a lot. It transforms something like:

 use File::Spec;

 my $filename = File::Spec->catfile(qw/some file/);
 open my $fh, '<', $filename or die "Failed to open $filename: $!";
 say do { local $/; <$fh> };


 use Path::Class;
 say scalar file(qw/some file/)->slurp;

If you work with the filesystem and do this all manually, Path::Class will make you very happy.

I'm a fan of `File::Spec::Functions` - it's generally cleaner than using the (allegedly) "object-oriented" interface in `File::Spec` but provides all the same functions.
Chris Lutz
  • CGI::Application
  • DBI
  • AnyEvent (I'm definitely a POE skeptic)
  • Template Toolkit

I would really not be able to function without the Win32::ODBC, I have so much old legacy code using this. I know DBI is better, but this module is used every second.


Lightweight, reliable, fast: classes - conventional Perl 5 classes


I agree with the strict comments, but i'd also be lost without CGI::Carp qw(fatalsToBrowser warningsToBrowser). It's tough to debug a script when your only hint is "Internal Server Error".

+1  A: 

Why? This module is the new awesomesauce in the realm of starting, building, testing, managing, cutting and releasing new Perl distributions.

As Perl's real strength is in its modules, its important that module maintainers lives are made as easy as possible when it comes to responding to bugs, and publishing fixes for bugs.

The faster this can be done, the earlier and more often releases can be performed.

Now, all I have to do to initialise a new distribution, is thus:

dzil new Distro-Name-Here

and that will get me started. After I've finished writing the code, all I have to do is this:

dzil release

And this will for me , perform a bunch of tasks that I'm so glad I'll never have to do manually again:

As you can see, it does for me so many awesome things, that it'd be impossible for me do to it all myself in a realistic timeframe, so it in fact enables me to do more cool things!.

In fact, I probably spent more time writing this answer than I spent on my last distribution :/

Kent Fredric