Veteran Perl developers will likely remember ActiveState’s Perl Package Manager (PPM), which was originally released in 2006 alongside ActiveState’s version of Perl 5.8, called ActivePerl 5.8. PPM greatly simplified adding CPAN modules with linked C libraries to your runtime environment by automatically compiling them for you. As a result, there was no need to maintain a build environment on your development system.

PPM became a staple for many Perl developers, but its efficacy has decreased over time. The underlying technology has not aged well, with the result that fewer and fewer Perl packages can be successfully built on more recent releases of Perl. Eventually, we made the decision to remove PPM from our ActivePerl 5.28 release as the vast majority of packages were failing to build.

However, the original PPM use case remains valid. We still have numerous requests from developers that have had their CPAN installation fail, and have tried to turn to PPM to solve their issue. It’s time for an update.

Modernizing Perl & Package Management

As the recent announcement of Perl 7 highlighted, open source language technology from past decades is often hamstrung by backward compatibility requirements that prevent it from easily fitting into modern development conventions. Periodically, a restart is required. ActiveState is taking a similar approach with our new package management solution, which is based on the ActiveState platform and it’s Command Line Interface (CLI), the State Tool. 

But to illustrate how package management has evolved, consider how Perl environment management has changed:

Managing Environments vs Dependencies:

Originally, it was enough to just be able to add or update one or more dependencies in an environment, and automatically compile any linked libraries on the fly. But as CPAN’s library of third party modules has grown, the chance for dependency conflicts arising as a result of that addition/update has also increased.

“Dependency Hell” has become a significant problem, typified by the use case where Module A requires Version 1 of Dependency X, but Module B requires Version 2 and won’t work with Version 1. If you’ve experienced it, you know how frustrating and time consuming resolving these kinds of errors can be. While there are a number of tools that can help you resolve these conflicts after they occur, there are very few that help prevent them from arising in the first place.

ActiveState will manage dependency conflicts for multiple operating systems for you (no more having to learn multiple tool sets per OS), and even track native dependencies to ensure that your environment “just works.”

Managing Virtual vs Global Installations:

As our developer survey showed, despite the fact that plenv and perlbrew have been around for years, most developers continue to work with a single, global language installation rather than following best practices to create a virtual environment for each project.

For ActiveState, package management includes not only dependency management but also environment management. With a single command, you can create a virtual environment and download the appropriate environment for each project you work on. Switching between environments is as simple as typing the name of the project. Did something go wrong? You can simply rollback to a previously working environment configuration with a single command.

No more need to actively manage multiple directories, or worry about corrupting any of your working or system language installations.

The ActiveState Platform and the State Tool are being designed to allow you to easily build and manage Perl environments by providing:

  • Automated resolution of dependency conflicts
  • Automated builds of environments for each of your projects
  • Automated creation of virtual environments on Windows and Linux platforms (macOS support is coming)
  • Ability to manage, rollback, switch between and share environments with a single appropriate command, as well as a number of other features.

The New PPM

As part of our package management evolution, we are currently in the process of replacing PPM with a combination of the ActiveState Platform and the State Tool.

Today, you can install the State Tool and then use it to create a free ActiveState Platform account and invoke PPM. At that point, the State Tool will walk you through adding a module/dependency to your environment, where:

  • The ActiveState Platform provides a catalog of buildable modules, and performs the build (including linked C libraries) for you.
  • The State Tool allows you to manage the modules/dependencies in your environment.

Currently, the process creates a virtual environment for your project, and then installs/updates the entire Perl environment for that project. For more information, refer to our PPM Community Forum Post.

However, the goal is to allow you to manage and update your environments on a per dependency basis. To that end, ActiveState will very soon be:

  • Supporting Perl 5.32 on our ActiveState Platform as a buildable environment, as well as releasing an ActivePerl 5.32 Community Edition (CE) for those that prefer pre-built environments.
  • Updating the State Tool to allow you to add modules/dependencies to your Perl 5.32 virtual environment without needing to rebuild it.

We believe the resulting solution will be better than the original PPM, able to reliably build far more dependencies, and provide you with more powerful tooling so you can better manage your environments and be more productive than ever.

While you’re waiting for the new PPM, you will want to get familiar with how the ActiveState Platform and the State Tool work today:

Related Blogs:

Advanced Package Management for Perl Projects

The Future of Perl at ActiveState – Part 1

Dependency Resolution Optimization – ActiveState’s Approach