If you search Google for “perl package management” the first result is still ActiveState’s Perl Package Manager (PPM). PPM allowed Perl developers to add modules, especially those with linked C libraries to their runtime without the need to maintain a build environment on their system. Unfortunately, it’s a technology whose time has come and gone. You can read more about how we are now addressing PPM’s use case in our blog post, Advanced Package Management for Perl Developers.
This post takes aim at the fact that organizations are forced to separately manage multiple tools, processes and systems for each programming language they use. And then typically manage the runtime environments for each of their dev, test and production systems separately, as well.
The issue stems from the fact that open source language package managers such as a CPAN client or Perl Package Manager (PPM) have traditionally had a very narrow use case: automate the process of installing, upgrading, configuring, and removing language components for a system in a consistent manner. At ActiveState, we’re asking the question, “what if a package manager could perform its traditional role across multiple languages for multiple developers on multiple OS’s?” After all:
- More and more applications are written in more than one language
- Most developers work in teams
- Many development team members/contributors work on their preferred OS
The Future of Package Management
If organizations had a single package management solution that could work across multiple OS’s and languages, and even coordinate deployment across multiple systems, traditional use cases for package management could evolve to:
Managing Team vs Individual Perl Environments
When it comes to installing Perl, each developer/contributor on a team typically implements it in as part of setting up their own dev environment. But out of date Readme files, differing system requirements, and inconsistently applied patches/updates mean that a team’s Perl environments are rarely in sync, leading to “works on my machine” issues. The result is a loss of productivity as devs spend time troubleshooting environments.
While ActiveState’s package management solution can be used to install, upgrade and maintain an individual developer’s Perl environment, it’s far more powerful when used to help manage environments across a team of developers. ActiveState provides a single source of truth for your project’s Perl environment on the ActiveState Platform that can be shared, installed and updated by all team members with a single command via our CLI, the State Tool.
The idea is to greatly reduce “works on my machine” issues so your team can spend more time coding and less time troubleshooting.
Managing End to End Deployments vs Each Environment
Just as there are typically differences between each developer’s Perl environment, there can often be differences between development, test and production Perl environments. Troubleshooting these differences results in productivity loss and shipping delays. While containers help, you still need to ensure each container is consistently built with the correct Perl environment.
Similar to coordinating the Perl environment for each developer’s system, ActiveState’s “single source of truth” approach can also ensure a consistent, reproducible Perl environment for all your test / CI/CD and production environments, as well.
Enabling Custom vs Standard Perl Environments for CI/CD
Most CI/CD solutions do a poor job of accommodating custom Perl environments. If you’ve had to vendor any of your dependencies, or need to pull a dependency from a private repo into a CI/CD container, you’ve probably experienced the pain. In response, DevOps have learned a series of tricks to make things work, with the unintended consequence that your CI/CD Perl environment may differ from your dev and production environments, resulting in inconsistencies and proliferation of “works on my machine” issues.
By pre-building the Perl environment on the ActiveState Platform, and using the State Tool to deploy it seamlessly into the container, DevOps no longer needs to wrestle with custom Perl environments across their CI/CD chain. As an example, read how you can use ActiveState to optimize Perl builds with GitHub Actions in our recent blog post.
We realize that this a big conceptual leap for most Perl-using organizations, and represents a significant departure from current best practices. But we also believe that if you give it a try, the benefits will be immediately obvious. “Trying it out” involves two components: the ActiveState Platform and its CLI, the State Tool.
The Next Generation of Perl Package Management
For managers of Perl projects, both commercial and open source, who are interested in the team/organization-wide package management capabilities outlined above, ActiveState provides two primary resources:
ActiveState Platform:
The ActiveState Platform provides a free, cross-platform “build farm in the cloud” that will automatically resolve dependencies, build your Perl environment from source, and then package it for Windows and Linux (Mac coming soon) – no language or OS expertise required. Today, you can use it to create a Perl environment that acts as the single source of truth for everyone working on your project.
But we know that teams often need a little nudge to adhere to corporate security and compliance policies, which is why we’re working on providing:
- Dependency Metadata – including CVE, license and versioning information. The goal is to programmatically ensure that whenever a developer adds a new dependency to the environment, they’re using components (including transitive dependencies, shared libraries, etc) that are CVE-free, and licensed according to corporate standards.
State Tool
As the CLI for the ActiveState Platform, the State Tool can be used in a number of ways to help simplify common package management tasks:
- Dependency Management – install, upgrade, configure, and remove individual dependencies from your Perl 5.32 environment managed on the ActiveState Platform. After making changes, the new environment can be shared across teams or used to refresh systems with a single command, ensuring your Perl environment is always up-to-date.
- Environment Management – State Tool always installs Perl into a virtual environment, thereby isolating dependencies and eliminating conflicts. This means users no longer need to actively manage multiple working directories, or worry about corrupting their system installation.
But the goal for the State Tool is to become a cross-platform, universal package manager. To do so, it will also need to be able to manage individual packages for any dynamic open source language. That’s a tall order, so we’ve open sourced the State Tool on GitHub as a resource that anyone can investigate, comment on, and contribute to. For more information on how ActiveState is open sourcing the State Tool, refer to our Meet The State Tool blog post.
Next Steps
Check out the ActiveState Platform catalog of buildable modules by forking a version of our ActivePerl 5.28 (requires a free account). Just click the Add Packages button to search for your favorite modules.
- Can’t find what you want? Let us know in the ActiveState Community forum.
- Learn more about our vision for the ActiveState Platform.
Install the State Tool and test out its ability to install a Perl runtime into an isolated virtual environment so you can work on multiple projects without conflicts. The easiest way to do so is just to download and install ActivePerl 5.26 or ActivePerl 5.28 since it comes with the State Tool.
Alternatively:
- On Windows, you can install the State Tool in PowerShell by running:
IEX(New-Object Net.WebClient).downloadString('https://platform.activestate.com/dl/cli/install.ps1') - If you’re on Linux or Mac, you can use curl to install the State Tool:
sh <(curl -q https://platform.activestate.com/dl/cli/install.sh)
Learn more about how to use the State Tool.
Related Blogs:
