What Is a Perl Module?
A Perl module is simply a file with a .pm extension that bundles related subroutines, variables, and (optionally) an object-oriented class definition so that other scripts can reuse them with a single 'use' statement. Modules exist to stop you from copy-pasting the same date-formatting routine or database helper into every script you write; instead you write it once, give it a package name, and 'use' it wherever needed. The Perl core ships with hundreds of modules already installed, such as List::Util, POSIX, and File::Basename, which cover common tasks without any extra installation.
Cricket analogy: Just as a franchise like Mumbai Indians keeps a reusable playbook of fielding drills that every age-group team draws on instead of reinventing training plans, a Perl module is a reusable playbook of code that every script can pull in with 'use'.
Installing Modules from CPAN
CPAN, the Comprehensive Perl Archive Network, is a public repository hosting well over 200,000 distributions ranging from JSON parsers to web frameworks like Mojolicious and Dancer2. Rather than browsing the CPAN website and manually downloading tarballs, most developers use the cpanm (App::cpanminus) command-line tool, which resolves dependencies, downloads source, runs the build and test suite, and installs the module into your Perl library path in one command. Because CPAN modules are peer-reviewed through automated CPAN Testers reports across many operating systems and Perl versions, installing a mature module like DBI or Moose is generally far safer than writing equivalent database or object-system code yourself.
Cricket analogy: Signing an experienced overseas all-rounder like Jofra Archer through the IPL auction instead of developing a rookie from scratch is like installing a battle-tested CPAN module such as DBI instead of writing your own database layer.
# Install the cpanm installer itself (one-time setup)
curl -L https://cpanmin.us | perl - App::cpanminus
# Install a module and all its dependencies
cpanm DBI
cpanm JSON::PP
cpanm Mojolicious
# Install a specific version
cpanm Moose@2.2015
# Install into a local, project-scoped directory (no root needed)
cpanm --local-lib=~/perl5 Try::Tiny
eval "$(perl -I ~/perl5/lib/perl5 -Mlocal::lib)"Loading Modules: use vs require
The 'use Module::Name;' statement is a compile-time directive: Perl loads and executes the module before the rest of the script compiles, which is why 'use strict;' and 'use warnings;' take effect immediately and why you can call imported functions anywhere in the file. 'require Module::Name;' is its runtime cousin — it loads the module only when that line actually executes, which is useful for conditionally loading a module inside an if-block, but it does not automatically import symbols the way 'use' does (you must call Module::Name->import() yourself if needed). Most application code should default to 'use' at the top of the file; 'require' is reserved for cases like optional plugin loading or avoiding a circular dependency.
Cricket analogy: Naming your playing XI before the toss, fully committed before play starts, is like 'use', which loads a module at compile time; calling up a substitute fielder mid-innings only if injury happens is like 'require', loaded only when that runtime path executes.
You can import only specific functions from a module instead of everything: 'use List::Util qw(sum max);' brings in just sum() and max(), which keeps your namespace clean and makes dependencies explicit at a glance.
Managing Module Versions
Because CPAN modules evolve independently of your application, version pinning matters: 'use JSON::PP 2.27;' fails fast with a clear error if an older, incompatible version is installed, rather than letting your script fail mysteriously later. Tools like cpanfile and Carton let you declare exact dependency versions for a whole project and reproduce that dependency set on another machine, which is essential for deploying the same application consistently across development, staging, and production servers. Checking a module's installed version with 'perl -MModule::Name -e "print $Module::Name::VERSION"' or 'cpan -D Module::Name' is a quick way to diagnose why behavior differs between two environments.
Cricket analogy: Specifying that a stadium pitch must be prepared to exact ICC standards before a Test match, not just 'roughly similar', is like pinning 'use JSON::PP 2.27;' so an incompatible older version fails immediately rather than causing subtle bugs later.
Never install CPAN modules as root into your system Perl without a local::lib or containerized environment in production — a bad module version upgrade can silently break every script on the server that depends on system Perl, including OS tooling on Debian-based systems that itself uses /usr/bin/perl.
- A Perl module is a .pm file bundling reusable subroutines, variables, or a class, loaded via 'use'.
- CPAN hosts 200,000+ community-reviewed distributions; cpanm is the standard installer that resolves dependencies automatically.
- 'use' loads and imports at compile time; 'require' loads at runtime and does not auto-import symbols.
- Import only what you need with 'use Module qw(func1 func2);' to keep namespaces clean.
- Pin exact versions with 'use Module 2.27;' or a cpanfile/Carton to guarantee reproducible deployments.
- CPAN Testers reports give confidence a module works across many OS/Perl-version combinations before you install it.
- Avoid installing into system Perl in production; use local::lib or containers to isolate dependencies.
Practice what you learned
1. What is the primary difference between 'use' and 'require' in Perl?
2. Which tool is most commonly used to install a module and its dependencies from CPAN?
3. What does 'use JSON::PP 2.27;' do if only version 2.10 is installed?
4. Why is local::lib recommended over installing CPAN modules into system Perl?
5. What is CPAN Testers?
Was this page helpful?
You May Also Like
Packages and Namespaces
Understand how Perl's 'package' keyword partitions global symbol tables to avoid naming collisions and how namespaces underpin every module and class.
Writing Your Own Module
Build, structure, document, test, and package a distributable Perl module from scratch, from the initial .pm file to a CPAN-ready distribution.
Object-Oriented Perl
Learn how Perl implements classes, objects, and inheritance using packages, blessed references, and the arrow operator, plus the modern Moose/Moo/class approach.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics