Skip navigation

Tag Archives: modern perl

A reasonable approach for Modern::Perl.

At YAPC::NA this morning, chromatic answered my question about Modern::Perl, “What happens when perl 5.12 comes out?”, with what I think is a good solution.

The proposed answer is for Modern::Perl to take a date parameter to indicate what “modern” means. This is brilliant because it explains to even the unknowledgeable programmer when the code was current. Say the syntax is like:

    use Modern::Perl as_of => '2009-06-23';

What could be more clear?

Dealing with perl binary compatibility issues as a user of XS modules.

chromatic discusses binary compatibility with the perl executable. I’m someone who only uses XS modules and hopes to never have to write one. Yet, unlike what seems to be the prevailing fear, I don’t worry about binary compatibility. I don’t worry about upgrades breaking things. I don’t worry that I’m going to have mismatches in executables/libraries.

Why? Continuous integration.

Don’t just grab modules from the CPAN and install them somewhere never to be upgraded until you’re forced to at a huge amount of time and expense. Regularly rebuild everything you use, preferably daily or hourly.

  1. Install a perl binary and then lock it down. Don’t use site dirs. Have the perl core be inviolate.
  2. Instead, install to some other directory and point PERL5LIB at it. Both CPAN and CPANPLUS allow you to configure what you want to be passed to the configuration program. Pass a value for INSTALL_BASE to Makefile.PL and install_base to Build.PL that points to your directory.
  3. Set up a build server to use CPAN or CPANPLUS to “install” and build everything. Since your build machine will be rebuilding everything regularly, when you upgrade your perl binary or an XS module, any problems will be quickly identified. Everything being rebuilt in one go means that all binary code will match up and you don’t have to worry about them getting out of sync. Because installing a distribution causes all of that distribution’s tests to be run, you’ll know that that distribution works in your environment.

(If you’re using taint mode and thus cannot use PERL5LIB, have your build machine build a custom perl executable along with everything else.)

Details for doing this belong in another post. But the point is, if you regularly rebuild all of the CPAN code you use, you don’t need to worry about binary issues.

The problem with Modern::Perl.

Modern::Perl has laudable goals. I agree with chromatic. This is why I use 5.10.0 at work. This is why I will be upgrading to 5.10.1 almost as soon as it is released. I even plan on testing our code with the 5.10.1 release candidates. The first significant line in all our modules is “use 5.010;“. (The second is “use utf8;“.) As I said in a prior post, I upgrade all the modules that we use from the CPAN every three months.

However, as a practical matter, Modern::Perl is broken. What happens when perl 5.12 comes out? Does chromatic upgrade the module to add “use feature qw/ :5.12 /;“? Are all of the modules that use Modern::Perl suddenly broken? Someone requested that TestingAndDebugging::RequireUseStrict include Modern::Perl in the default set of modules that are treated as equivalent to “use strict;“. (You can add to that list yourself via the “equivalent_modules” option.) I don’t want to do that; I want to discourage the use of Modern::Perl. Maybe if there was a Modern::Perl_5_10 I’d think differently.

Modern Perl