Back in July 2020, we made a few promises to our community of ActivePerl users in the first part of our Future of Perl at ActiveState blog post, which included:
- ActivePerl 5.32 would be released in the second half of 2020 on the ActiveState Platform
- A replacement for Perl Package Manager (PPM)
- A follow up post, which you‘re now reading
It’s been three very busy months in which we’ve been hard at work listening to our customer base and applying their feedback to what we’re building. That process has raised three key issues that we’ve been working through as we try to determine what the future of ActivePerl might look like. Each of these issues has greatly informed our way forward, and while they represent some significant changes, we believe they’re for the better.
#1 Perl Virtual Environments
ActivePerl has always been installed globally by default. This matches the way that most developers have been used to working with Perl for decades. But times are changing. More and more we hear from Perl users who are focused on maintaining and updating existing Perl codebases, rather than creating new ones. And they’re often responsible for maintaining more than one codebase at a time.
Working on multiple Perl projects that don’t share the same Perl version or dependencies is a non-starter with global installations. That’s why plenv and perlbrew exist: to help set up working directories isolated from each other, thereby ensuring against dependency conflicts and environment corruption.
Perl’s existing virtual environment offerings are all good, but that doesn’t mean they can’t be improved upon. We’ve built virtual environment features into the State Tool, which is the command-line interface for the ActiveState Platform. The State Tool offers:
- A native way to install ActivePerl into working directories with a single command
- A simpler way to manage multiple projects by listing, switching between, updating, restoring, forking, and even sharing them with your team members using a single appropriate command
- Cross-platform support, including Windows and Linux (Mac support coming)
- Cross-language support, including Perl and Python (more languages coming)
Those used to working with virtual environments will find much to like in the State Tool’s implementation. Those that haven’t worked with virtual environments previously maybe a little lost at first, but we’re working on a quick start tutorial that should help ease you into the habit.
While the State Tool is still a work in progress, you can give it a try today with our existing ActivePerl 5.28 and 5.26 builds:
For Windows users, run the following in Powershell:
IEX(New-Object Net.WebClient).downloadString('https://platform.activestate.com/dl/cli/install.ps1')
Then type the following at a cmd prompt:
state activate ActiveState/ActivePerl-5.28
For Linux users, just run the following two commands:
sh <(curl -q https://platform.activestate.com/dl/cli/install.sh) state activate ActiveState/ActivePerl-5.28
To learn more about working with the State Tool, refer to the documentation.
#2 The End of One-Size-Fits-All Perl Environments
When we embarked on our project to build out what has become the ActiveState Platform, our first use case was to provide ourselves with a better, automated way to build our Community Editions of ActivePerl, ActivePython and ActiveTcl. After all, handcrafting these distributions was taking longer and longer, delaying our time to market.
The primary reason for this delay was complexity. ActivePerl has grown from including a few tens of modules to hundreds, and CPAN keeps adding more potentially-included modules every year. Patching, building, and debugging each of them in isolation was a growing burden, but when they’re added together in a single distribution complexity increases a hundredfold.
But this kind of complexity extends well beyond just ActiveState building a distribution. It also impacts any organization that continues to deploy large Perl environments. As Synopsis continues to point out every year in their Open source Security & Risk Analysis report:
- 49% of code bases contain high-risk vulnerabilities
- 67% of code bases contain license conflicts, which occur when a codebase contains one or more modules whose licensing terms appear to be at odds with the overall license of the codebase
- 82% of code bases contain components more than 4 years out of date
As discussed in our Why Use Custom Perl Environments? blog post, the larger the Perl environment, the greater these risks.
As a result, ActivePerl 5.32 will not provide a one-size-fits-all Community Edition. Instead, you’ll be able to select bundles of modules by functionality (testing bundle, webdev bundle, etc), which will be built on demand from source code in order to create an environment that contains just those dependencies your project requires. In this way, you’ll be able to mitigate the risks raised in the Synopsis report by:
- Reducing the size, and therefore the number of vulnerabilities in your Perl environment
- Ensuring against license conflicts by excluding non-compliant dependencies
- Ensuring environments can always contain the latest version of dependencies
And of course, reducing costs in terms of resources required to create, manage and update large, one-size-fits-all Perl environments.
#3 Server-Side Compiling of Perl Modules
Veteran Perl developers are used to maintaining a build environment on their system to make sure they can always compile any dependencies that may require it. But not every Perl developer has the time, resources or inclination to build dependencies from source.
In fact, building Perl from source is becoming more and more of a lost art. That may be partly our fault, since for well over a decade ActiveState’s Perl Package Manager (PPM) would build your Perl dependencies for you. Unfortunately, the number of modules that PPM can build has shrunk over time as the underlying technology has aged to the point where we finally had to remove it from ActivePerl 5.28.
But as PPM users continue to tell us, the use case remains valid: how can Perl developers add dependencies with linked C libraries to their environment without having to:
- Maintain and update a C compiler environment on their local system
- Learn more than they may like about build scripts and OS installers/packagers
- Resolve dependency conflicts at the module and OS level
- Compile each module/dependency from source code, and resolve the inevitable issues that arise.
With ActivePerl 5.32, we are introducing a new way to automatically build any dependencies you may require, and add them to your existing ActivePerl environment. Similar to PPM, your dependencies will be built remotely, this time on the ActiveState Platform.
The ActiveState Platform features a catalog of almost all the Perl modules in CPAN, and it’s updated daily to ensure you always have access to the latest versions. While not every dependency is buildable at every point in time for every operating system, the ActiveState Platform will allow you to build far more Perl dependencies than PPM ever did.
Think of it as an on-demand build farm in the cloud that you can tap into via the State Tool whenever the need arises. The ActiveState Platform saves each version of your Perl environment and will update the latest with your requested module, automatically resolve it against your environment’s dependencies, and build it from source. You can then update your local environment with the newly added dependency.
In this way, you can update your Perl environment one dependency at a time, rather than having to update the entire environment as required with previous versions of ActivePerl. For more information on our replacement for PPM, read our Advanced Package Management For Perl Developers blog post.
We are still on track to release ActivePerl 5.32 and our PPM replacement in the second half of 2020. At that time, we look forward to hearing about your experience with it, but in the meantime, we’d be happy to address any potential concerns you may have in our Community Forums.
UPDATE: ActiveState introduced a new version of our Perl ecosystem with the release of Perl 5.32, which provides a new way to install, work with and even consume Perl from ActiveState. You can learn more and download your own version of ActiveState’s new Perl ecosystem for free from our Perl 5.32 page.
