cpm v1: making installs stable

I’m happy to announce cpm v1.

This release is not just a collection of small improvements. It is a fairly large redesign of how cpm prepares dependencies, builds distributions, and installs them. The main goal was to make installs more stable and more predictable, especially in cases with many dependencies and parallel work.

A large part of cpm v1 exists to fix a long-standing installation stability problem around partially built local libraries and a changing dependency environment.

What is new in cpm v1

At a high level, cpm v1 brings these changes:

• cpm v1 mostly fixes a long-standing installation stability problem.
• cpm now separates dependency preparation from final installation, and by default installs only the requested distributions and their runtime dependency closure.
• Terminal progress output now makes it much easier to see what cpm is doing and which step is taking time.
• The minimum supported Perl version is now v5.24.

The long-standing installation stability problem

For a long time, cpm had an installation stability problem. This had been discussed before in issue #71 and issue #178.

The short version is this: cpm would build up local/lib while it was still in the middle of installing other distributions, and it would also use that changing local/lib as part of the dependency environment for later configure/build/test steps.

That meant the effective @INC seen by one distribution could change while another distribution was still being processed. A dependency might appear halfway through an install, or the set of available modules might differ between configure time and build time. In the worst cases, this could break a distribution’s build or test process in ways that were hard to predict and hard to reproduce.

Update: I originally wrote that this problem was not unique to cpm and was not caused only by parallel installation. On reflection, that was too broad. More precisely, the problem discussed in this section was fundamentally caused by parallel installation into a shared local/lib. One distribution could observe modules from another distribution while they were still being copied into place, or before that distribution had reached a consistent installed state. That made the dependency environment race-prone, and it could break builds or tests in ways that were difficult to predict and difficult to reproduce.

How cpm v1 fixes it

The key change in cpm v1 is that dependency preparation and final installation are now treated as separate things.

Instead of relying on a partially constructed local/lib while installation is still in progress, cpm now treats already prepared dependencies as isolated dependency sources. In practice, this means cpm can use the built artifacts of dependencies directly, via blib/lib and blib/arch, and pass them through PERL5LIB in a controlled way when building or testing dependent distributions.

The general direction was not invented from scratch. Carmel and CPAN.pm already contained an important hint for solving this kind of problem: built artifacts can be treated as dependency sources through blib.

cpm v1 did not invent that idea, but it adopts it much more explicitly as the foundation of cpm’s install model.

As part of this change, cpm also no longer depends on cpanm or local::lib. That was not just cleanup. It was part of making cpm manage its own dependency environment directly, instead of relying on another tool’s assumptions.

Runtime-only install is now the default

Once dependency preparation and final installation were separated, cpm no longer had to install everything immediately just to keep the process moving.

That made it possible to decide what should actually be installed at the end. In cpm v1, the default is now to install only the requested distributions and their runtime dependency closure.

The terminal progress output is much better now

cpm v1 also improves the terminal progress output quite a bit.

The old output was not necessarily bad, but it was often hard to tell what cpm was doing right now, especially during longer installs or when one particular distribution was taking a long time. If an install looked slow, it was not always obvious whether cpm was stuck, building something large, or waiting on a test phase.

The new terminal progress output is much better at showing the current state of the install. In particular, it is easier to see what is happening now and which step is taking time. I think this makes cpm feel much less mysterious during long runs.

Why cpm v1 now requires Perl v5.24

cpm v1 now requires Perl v5.24 or later.

I understand that some people care a lot about keeping support for older Perl versions, and I understand the instinct to avoid raising the minimum supported version unless there is a truly unavoidable reason.

At the same time, Perl itself keeps moving forward every year. New versions are released, new features are added, and usability keeps improving.

But a large part of CPAN still declares very old minimum Perl versions such as v5.8 or v5.10, and as a result it often feels like we are deliberately refusing to take advantage of Perl’s progress.

I do not think that is a good direction. I think we should actively use newer Perl versions and newer language features.

So for cpm v1, I decided to raise the minimum version to v5.24, following The Lyon Amendment to the Lancaster Consensus.

This also let me remove a fair amount of code that existed only to support older Perl versions. The codebase is cleaner now, and I was also able to use features like signatures and lexical_subs, which I think made the implementation easier to read and maintain.

Thanks

I also want to thank a few people.

First, thanks to eserte and oalders for reporting and discussing the long-standing installation stability problem. cpm v1 would not look the way it does without those bug reports and discussions.

I also did the final push toward cpm v1 during Perl Toolchain Summit 2026, so I want to thank the organizers and sponsors for making that event happen.

Sponsors: The Perl and Raku Foundation, Grant Street Group, Geizhals Preisvergleich, Vienna.pm, SUSE, Trans-Formed Media LLC, Ctrl O, Simplelists, Harald Joerg, Michele Beltrame (Sigmafin), and Laurent Boivin.

And in particular, thanks to thibaultduponchelle, who tried the cpm v1 trial releases during PTS 2026 and reported problems in the terminal progress output. That feedback directly helped improve the final result.

Try cpm v1

If you are already using cpm, I hope you will give v1 a try.

If you run into problems, please open an issue. In particular, I would be very interested in reports about dependency handling, runtime-only installation, and terminal progress output.