Reconciling Bicameral Perl with Library Paths

I promised to offer two partial solutions to the gap between "Stable at all costs" Perl and "Please join us in the 20th century" Perl in The Two Worlds of Perl Deployment. The first solution already exists, technically. I haven't see anyone take advantage of it yet.

First, please read Jess Robinson's The two aspects of Perl for a different explanation of the same problem. (I should have linked this from the first article, because it helped me crystallize my thoughts.)

Localizing Change

One of the most persistent lessons of language design I've learned from Perl 5 is to avoid change-at-a-distance. Magical global variables are troublesome in Perl 5 -- not primarily because they can be difficult to read and remember unless you use them all the time, but because they're global to your process. One of my favorite features of Perl 6 that people will notice only in the absence of problems is that many of the lovely and useful features of Perl 5 are still present but now have proper lexical scoping. Autoflush is now a property of output filehandles. So is the input record separator.

The principle of localizing change applies also to Perl installations. The Mac OS X Perl upgrade problem comes from two different packaging systems trying to manage the same files. Similar problems come from upgrading other core modules, such as Scalar::Util.

Localizing Libraries

While the right long-term solution is Hanging the Core out to DRY and removing everything from the core, a simpler short-term solution exists and works today.

Perl 5 allows you to specify alternate installation paths for Perl libraries -- including core libraries. This is useful for installing CPAN modules locally when you don't have root permissions on a box. You can specify additional directories on the command line with the -I flag, add directories to the PERL5LIB environment variable, add code to the sitecustomize.pl flag (see the sitelib member of the Config module, or add use lib 'foo'; lines to a program.

OS vendors who package and distribute Perl and use it for core utilities should install their core libraries in a specific directory accessible only by their core utilities and they should configure Perl to install modules from the CPAN in another directory where their utilities do not look.

That is, if you distribute Perl as part of an OS or distribution, and you distribute Perl utilities which the system needs to function, you must pay attention to specific library versions and ensure that the proper library versions are available, even if users install newer versions from the CPAN.

Allowing users to install new versions which overwrite old version which an OS version might downgrade or sidegrade invites the type of trouble Apple users have seen lately.

This is merely a configuration problem, though the Perl 5 Porters should provide a simple guide for packagers which explains the solutions. (Note that pumpking Nicholas Clark has worked on reordering Perl 5's library search order to ameliorate some problems here.)

Similarly, admins and other Perl users who wish to enforce stability should consider segregating library paths for individual applications as necessary. A little bit of disk space is a cheap way to reduce unintentional collisions.