What Perl module would you be lost without?


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...


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.


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.)


CPAN.pm -- because it's my gateway to all the great libraries that people have already written to make my job easier.


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


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...



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.


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.


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

  • 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.

'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.


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


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.


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.


Damian Conway's Smart::Comments, and I use YAML for a bit of modeling (see yaml.org, 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.


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.


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.


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


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.


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

For package testing, I would also not do without:


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


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.


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


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


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.


I would be lost without many Perl modules. Test::More, Cwd.pm, Template-Toolkit, String::ShellQuote, DBI, CGI.pm, 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.


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).


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


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


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.

  • Carp
  • LWP::*
  • DBI
  • Data::Dumper
  • forks

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.


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


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 :/


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

  • 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.


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".


Encode is my choice here, while I'm frequently in need of LWP, DBI, CGI, and SAP::Rfc - I would be "out of Perl" whithout anyone of these. Without AUTOLOAD, SELFLOADER, Hash::Util qw(lock_keys), strict, and a few others I wouldn't be lost, but rather uncomfortable writing object modules.

  • File::chdir: a clever, platform independent way to manage the working directory
  • PDL: numerical mathematics in my favorite high-level language

I'd have to agree with CGI and DBI, though dumper is so hard handy. Recreating the functionality of either CGI or DBI would be such a huge chore. Could you imagine having to create sockets to your database server every time you want to do anything with it? What a nightmare that would be. But CGI has almost every HTML tag known to man inside it and can just do so much, plus you have CGI::Carp which has fatalsToBrowser, with which I'd be completely lost without; digging through logs, that I am not authorized to access on my work's web server.


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