Stop using your system Perl
Recently, Gabor ran a poll in a Perl Facebook community asking which version of Perl people used in their production systems. The results were eye-opening—and not in a good way. A surprisingly large number of developers replied with something along the lines of _“whatever version is included with my OS.”_
If that’s you, this post is for you. I don’t say that to shame or scold—many of us started out this way. But if you’re serious about writing and running Perl in 2025, it’s time to stop relying on the system Perl.
Let’s unpack why.
* * *
## What is “System Perl”?
When we talk about the _system Perl_ , we mean the version of Perl that comes pre-installed with your operating system—be it a Linux distro like Debian or CentOS, or even macOS. This is the version used by the OS itself for various internal tasks and scripts. It’s typically located in `/usr/bin/perl` and tied closely to system packages.
It’s tempting to just use what’s already there. But that decision brings a lot of hidden baggage—and some very real risks.
### Which versions of Perl are officially supported?
The Perl Core Support Policy states that only the **two most recent stable release series** of Perl are supported by the Perl development team [**Update:** fixed text in previous sentence]. As of mid-2025, that means:
* Perl 5.40 (released May 2024)
* Perl 5.38 (released July 2023)
If you’re using anything older—like 5.36, 5.32, or 5.16—you’re outside the officially supported window. That means no guaranteed bug fixes, security patches, or compatibility updates from core CPAN tools like `ExtUtils::MakeMaker`, `Module::Build`, or `Test::More`.
Using an old system Perl often means you’re **several versions behind** , and no one upstream is responsible for keeping that working anymore.
* * *
## Why using System Perl is a problem
### 1. It’s often outdated
System Perl is frozen in time—usually the version that was current when the OS release cycle began. Depending on your distro, that could mean Perl 5.10, 5.16, or 5.26—versions that are **years** behind the latest stable Perl (currently 5.40).
This means you’re missing out on:
* New language features (`builtin`, `class/method/field`, `signatures`, `try/catch`)
* Performance improvements
* Bug fixes
* Critical security patches
* Support: anything older than Perl 5.38 is no longer officially maintained by the core Perl team
If you’ve ever looked at modern Perl documentation and found your code mysteriously breaking, chances are your system Perl is too old.
### 2. It’s not yours to mess with
System Perl isn’t just a convenience—it’s a dependency. Your operating system relies on it for package management, system maintenance tasks, and assorted glue scripts. If you install or upgrade CPAN modules into the system Perl (especially with `cpan` or `cpanm` as root), you run the risk of breaking something your OS depends on.
It’s a kind of dependency hell that’s completely avoidable—**if you stop using system Perl**.
### 3. It’s a barrier to portability and reproducibility
When you use system Perl, your environment is essentially defined by your distro. That’s fine until you want to:
* Move your application to another system
* Run CI tests on a different platform
* Upgrade your OS
* Onboard a new developer
You lose the ability to create predictable, portable environments. That’s not a luxury—**it’s a requirement for sane development** in modern software teams.
* * *
## What you should be doing instead
### 1. Use `perlbrew` or `plenv`
These tools let you install multiple versions of Perl in your home directory and switch between them easily. Want to test your code on Perl 5.32 and 5.40? `perlbrew` makes it a breeze.
You get:
* A clean separation from system Perl
* The freedom to upgrade or downgrade at will
* Zero risk of breaking your OS
It takes minutes to set up and pays for itself tenfold in flexibility.
### 2. Use `local::lib` or `Carton`
Managing CPAN dependencies globally is a recipe for pain. Instead, use:
* `local::lib`: keeps modules in your home directory.
* `Carton`: locks your CPAN dependencies (like `npm` or `pip`) so deployments are repeatable.
Your production system should run with _exactly_ the same modules and versions as your dev environment. Carton helps you achieve that.
### 3. Consider Docker
If you’re building larger apps or APIs, containerising your Perl environment ensures true consistency across dev, test, and production. You can even start _from_ a system Perl inside the container—as long as it’s isolated and under your control.
You never want to be the person debugging a bug that _only happens on production_ , because prod is using the distro’s ancient Perl and no one can remember which CPAN modules got installed by hand.
* * *
## The benefits of managing your own Perl
Once you step away from the system Perl, you gain:
* **Access to the full language.** Use the latest features without backports or compatibility hacks.
* **Freedom from fear.** Install CPAN modules freely without the risk of breaking your OS.
* **Portability.** Move projects between machines or teams with minimal friction.
* **Better testing.** Easily test your code across multiple Perl versions.
* **Security.** Stay up to date with patches and fixes on _your_ schedule, not the distro’s.
* **Modern practices.** Align your Perl workflow with the kinds of practices standard in other languages (think `virtualenv`, `rbenv`, `nvm`, etc.).
* * *
## “But it just works…”
I know the argument. You’ve got a handful of scripts, or maybe a cron job or two, and they seem fine. Why bother with all this?
Because “it just works” only holds true until:
* You upgrade your OS and Perl changes under you.
* A script stops working and you don’t know why.
* You want to install a module and suddenly `apt` is yelling at you about conflicts.
* You realise the module you need requires Perl 5.34, but your system has 5.16.
Don’t wait for it to break. Get ahead of it.
* * *
## The first step
You don’t have to refactor your entire setup overnight. But you _can_ do this:
* Install `perlbrew` and try it out.
* Start a new project with `Carton` to lock dependencies.
* Choose a current version of Perl and commit to using it moving forward.
Once you’ve seen how smooth things can be with a clean, controlled Perl environment, you won’t want to go back.
* * *
## TL;DR
Your system Perl is for your operating system—not for your apps. Treat it as off-limits. Modern Perl deserves modern tools, and so do you.
Take the first step. Your future self (and probably your ops team) will thank you.
### Share this:
* Tweet
* * Click to share on Reddit (Opens in new window) Reddit
* More
*
* Click to email a link to a friend (Opens in new window) Email
* Click to print (Opens in new window) Print
* * Share on Tumblr
* Pocket
* *
### _Related_
Stop using your system Perl Recently, Gabor ran a poll in a Perl Facebook community asking which version of Perl people used in their production systems. The results were eye-opening—and not in a...
#Programming #carton #docker #perlbrew #system #perl
Origin | Interest | Match
