What Perl module would you be lost without?

Question

What Perl module would you be lost without?

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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.

Answer 6

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

Answer 7

• DBIx::Simple so I don't have to use DBI directly :P
• Test::More, because every module needs a test suite
• libwww-perl, especially the HTTP:: parts

Answer 8

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.

Answer 9

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.

Answer 10

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

Answer 11

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

Answer 12

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.

Answer 13

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

Answer 14

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.

Answer 15

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.

Answer 16

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.

Answer 17

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.

Answer 18

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.

Answer 19

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

Answer 20

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

Answer 21

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.

Answer 22

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

Answer 23

Getopt::Long

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.

Answer 24

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

Answer 25

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

Answer 26

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

Answer 27

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.

Answer 28

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

Answer 29

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

• Getopt::ArgvFile (complimenting Getopt::Long)
• Config::IniFiles
• Data::FormValidator
• Image::Magick

For package testing, I would also not do without:

• Test::More
• Test::MockObject
• Test::Pod
• Test::Pod::Coverage
• Test::CPAN::Meta
• Devel::Cover

Answer 30

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

Answer 31

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

$self->horn->toot;

Answer 32

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

Answer 33

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.

Answer 34

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

Answer 35

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> };

Into:

 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.

Answer 36

• CGI::Application
• DBI
• AnyEvent (I'm definitely a POE skeptic)
• Template Toolkit

Answer 37

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.

Answer 38

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

Answer 39

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

Answer 40

• Dist::Zilla

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:

• Generate a sane and predictable version number for the release based on the time
  
  • Plugin::AutoVersion
  • Plugin::AutoVersion::Relative
• Build a file tree of the files in my distribution, sans a load of junk files
  • Plugin::GatherDir
  • Plugin::PruneCruft
• Put MetaData in the distribution about where it can be found on Github ( Both Http browsing and git checkout urls ):
  • Plugin::GithubMeta
• Inject a LICENSE file of my chosing, with appropriate copyright holder/author information templated into it:
  • Plugin::License
• Visit all my .pm files and inject the magical $VERSION = lines containing the above determined version number.
  • Plugin::PkgVersion
• Reformat all my POD to my liking, that is, shove it down to after _END_
  • Plugin::PodWeaver
• Produce Metadata about what versions of which modules are shipped in this distribution, in order to make the PAUSE indexer more predictable.
  • Plugin::MetaProvides::Package
• Nicely format the POD of my main module into a human readable text-file README
  • Plugin::ReadmeFromPod
• Auto Produce a MANIFEST and apply any rules I might have from MANIFEST.skip files to remove unwanted files from the dist.
  • Plugin::Manifest
  • Plugin::ManifestSkip
• Automagically scan all my .pm and .t files for use declarations, and put them into the distributions "Prerequisite" data.
  • Plugin::AutoPrereq
• Permit me to manually define which versions of some of those prerequisites I want as dependencies.
  • Plugin::Prereq
• Generate package Metadata about what versions of the prerequisites me, the releaser of the module, had installed at the time of release.
  • Plugin::MetaData::BuiltWith
• Inject the current version number at the head of my Changes file.
  • Plugin::NextRelease
• Inject a whole bunch of extra tests that I like testing every module for.
  • Plugin::CompileTests
  • Plugin::MetaTests
  • Plugin::PodCoverageTests
  • Plugin::PodSyntaxTests
  • Plugin::ReportVersions::Tiny
  • Plugin::KwaliteeTests
  • Plugin::PortabilityTests
  • Plugin::EOLTests
  • Plugin::ExtraTests
• Generate a META.json and META.yml file containing all the metadata.
  • Plugin::MetaJSON
  • Plugin::MetaYAML
• Generate a Module::Build package installation script.
  • Plugin::ModuleBuild
• Tar up all of the above into a .tar.gz file. ( Implicit functionality )
• Extract a copy of my now built distribution into a temporary directory. ( Implicit Functionality )
• Simulate building the distribution.
  • Plugin::ModuleBuild
• Run tests that were marked as "Release Tests"
  • Plugin::TestRelease
• Ask Me whether or not I really want to upload it to CPAN
  • Plugin::ConfirmRelease
• Checks that Git is happy that there are no uncommited files in the distribution.
  • Plugin::Git::Check
• Tags the current branch in Git with my current version.
  • Plugin::Git::Tag
• Updates my local copy of my Changes file.
  • Plugin::NextRelease
• Commits the updated changes file to git.
  • Plugin::Git::Commit
• Uploads my tar.gz file to CPAN
  • Plugin::UploadToCPAN
• Publishes a link on twitter about the release, linking to the releases Changelog on CPAN.
  • Plugin::Twitter

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