Removing Modules from Core

I was on holiday last week and missed most of the discussions about removing Module::Build and CGI from the Perl core in the next few years. I hope you won’t mind if I chime in a little late with my thoughts.

Module::Build

I’m a little bemused by the Module::Build story. Well, perhaps “bemused” isn’t quite the right word. Perhaps I should say “embarrassed”. Embarrassed because the discussions around Module::Build just show how out of touch I am with important parts of the Perl ecosystem.

I remember seeing Schwern’s MakeMaker Is DOOMED! talk ten years ago. What he said made a lot of sense to me and I switched all of my CPAN modules to Module::Build over the next few years. And then I rather took my eye off the ball. I was vaguely aware that people were complaining about Module::Build and were switching to things like Module::Install and Dist::Zilla. But I was happy with Module::Build and just stuck with it.

Now I’m hearing people saying that Module::Build is fundamentally flawed. Someone whose opinion I value mentioned that he lowers his estimate of the IQ of any CPAN author who uses Module::Build. That, presumably, includes me. But when I ask people what the problems are with Module::Build, I can’t get anyone to give me a detailed and dispassionate answer.

I’m quite prepared to believe that there are problems with Module::Build. Given the calibre of the people who are telling me that these problems exist, it would be astonishing if it wasn’t true. But it would be nice if there was a good explanation available somewhere of just what these problems are.

And I think that this is indicative of a deeper problem that the Perl community has. I like to think that I’m pretty much in touch with what is going on in the Perl community. I read the blogs. I’m subscribed to (too many) mailing lists. But it appears I’m not following discussions of the CPAN toolchain closely enough. I guess it’s something that I just expect to work. And I guess I expect that if there are important discussions going on, then I’ll hear about them through other channels – blog posts, for example. But that doesn’t seem to have happened here. Of course I can subscribe myself to another mailing list or two to correct that, but I don’t think I’m unusual in not trying to follow every single Perl discussion. There are surely many people like me who would like information like this to be disseminated better. This is part of the reason why Leo and I set up the Perl News site. But we have a tiny number of editors and we can’t know everything that is worth publishing. If you think we’ve missed an interesting story then please let us know about it.

So I’m not going to object to Module::Build leaving the core. I’m sure there are good reasons, I just wish I knew what they are. I am, however, slightly disappointed to find that Schwern was wrong ten years ago and that ExtUtils::MakeMaker wasn’t doomed.

CGI

CGI.pm and I go back a long way. In fact I think CGI.pm was added to the Perl core at about the same time as I started using Perl.

It’s obvious why it was added to the core. Back in 1997, Perl and CGI were tightly bound together in many people’s minds. I had people telling me that Perl could only be used to write CGI programs and other people telling me that CGI programs could only be written in Perl. Both sets of people were, of course, wrong; but it’s easy to see how they reached both of those conclusions.

Before CGI.pm was added to the Perl core, people used to parse CGI parameters using horribly broken code copied from Matt Wright (code which he had originally copied from Reuven Lerner). Of course, adding the module to the Perl core didn’t magically rewrite all those horrible CGI programs to use CGI::params, but at least it meant that the option was there.

This became important to me when I started the nms project. This project rewrote Matt Wright’s scripts using a better standard of Perl code. The problem was that many people started by installing one of Matt’s scripts on their server and later, when they wanted to move on from using other people’s code, they would use Matt’s code as a template for their own first steps into Perl. This is partly what made Perl so popular. But it’s also what lead to the preponderance of terrible Perl code that you still find on the web today.

We wrote the nms programs to work, as far as possible, in the same environment as Matt’s scripts. Matt said that his scripts would work fine on Perl 4 (back then, there were still many cheap hosting plans that came with Perl 4). We decided not to put ourselves through that pain and to target Perl 5.004 – because that was the first version to include CGI.pm. Remember, we were targeting Matt Wright’s users. And they were people who used cheap hosting plans with basic FTP access and little or no chance of installing anything from CPAN. We had to rely on core modules. If CGI.pm hadn’t been in the Perl core, then the nms programs would have been far harder to write and the project may have never been started.

The nms project was started over ten years ago. What is the situation like now? Those cheap hosting plans still exist. People still use them for simple web sites. Some of those people still use Matt’s scripts or the nms alternatives. But the numbers of people using those programs are far smaller than they used to be. These days, people wanting to add simple dynamic functionality to a web site are far more likely to use a PHP program. And those cheap web hosts are far more likely to want to support PHP.

Of course, these days, no serious Perl developer uses CGI.pm to write web programs. We’d be far more likely to use something based on PSGI. And even if we did want to use CGI.pm, we’d know how to get it installed from CPAN. The only people who are going to suffer from the removal of CGI.pm are the people using something like the nms programs on a cheap hosting plan. I worry a little about the influx of support email we will get when some cheap hosting company updates from Perl 5.18 to Perl 5.22 and suddenly all the nms programs stop working. It’s slightly galling to realise that Matt’s scripts will continue to work at that point. Of course, the kinds of companies that we’re talking about tend to lag well behind the bleeding edge of Perl versions, so this might not happen for eight or more years. So I think it might well be someone else’s problem.

All in all, I think it will be sad to see CGI.pm removed from the core. It will effectively see the end of even half-decent Perl code being used on bottom of the range hosting plans. But Perl has been losing that market for years and, speaking as someone who spent a lot of time helping out on support forums for basic Perl/CGI code, I’m far from convinced that I’ll miss those users. So my sadness at seeing CGI,pm go, will be purely historical.

But I’d really like to see some cut-down version of PSGI take its place!

XML::Feed

XML::Feed is the module that does most of the heavy lifting for Perlanet and, as such, it powers some important parts of the Perl community’s infrastructure. Unfortunately, for a while now it’s had a rather long list of outstanding bugs that weren’t getting fixed.

Sometime last year, Matt Trout got co-maintainership on the module and shortly afterwards he shared it with me. I released a couple of versions last year (largely to fix one particular and important bug) and fixed a few of the easier bugs on the list, but most of the list remained untouched.

Whilst working on these few fixes I set up a copy of the repository on Github. And about a month ago, that started to pay dividends as I got a couple of pull requests from Gabor. In combination with a couple of new bug reports that came it at about the same time, this galvanised me into putting a bit more effort into the module.

I’ve released a couple of new versions in the last week. Most importantly, I think that version 0.48 fixes the test failures that were common in the last few releases – and initial indications are that I’m right.

It seems that people are interested in this module. So let’s see if we can get a little community going. I’ve set up a mailing list to discuss the module and. of course, there’s already the bug list and the Github repository.

Patches welcome. Github pull requests even more so. But if you just have ideas and suggestions or want advice on how to use the module, I’d love to hear from you.

Perl Versions

There has been a flurry of Perl 5 releases over the last few days and there’s some evidence that this has confused a few people. So let’s take a closer look at what is available.

Perl 5.14.1
This is the most advanced stable version of Perl 5 currently available. It was released on 17th June. If you’re looking for the best version of Perl to use then this is the one to go for unless you have a good reason to choose one of the other versions mentioned below.

I’ve heard people mention the “stable Perl versions have an even number” rule as a possible reason not to use this version. They are wrong. That rule only applies to the middle integer in the Perl version number. Perl 5.10, 5.12 and 5.14 are stable versions. Perl 5.11, 5.13 and 5.15 are not. 5.14.1 is 5.14.0 with bug fixes. It is stable.

Perl 5.12.4
This version was released on 20th June. Due to a bug in CPAN, it currently shows as the most recent stable version of Perl. Well, maybe it’s not a bug as, strictly speaking, it is the most recent stable version of Perl. This version is a maintenance release on the 5.12.x branch. It fixes some bugs in version 5.12.3. Version 5.14.x is (obviously, I hope) a more advanced branch than 5.12.x. This release is intended for people who are tied to the 5.12.x branch for some reason. They get some bugs fixes but don’t have to switch to a whole new major version of Perl 5. Unless you’re tied to 5.12.x, you don’t need this version.

Perl 5.15.0
This version was released today (on 21st June). It is the first release in the 5.15.x development branch. This is the branch that will (in ten months or so) become Perl 5.16. The “stable Perl versions have an even number” rule applies to this version as the middle integer is 15. That’s an odd number. This is an unstable release.

That’s not to say you shouldn’t use this release. It has been released for a very good reason. The Perl 5 Porters would very much like you to download and try out this new version of Perl and report back to them with any problems that you see. But you shouldn’t consider putting it into production.

I hope that clear things up. If you’re wary of leaping to 5.14.x for some reason, then use 5.12.4. If you want a sneak preview of how Perl might look this time next year, then use 5.15.0. But most of you should be installing 5.14.1.

Fedora and Centos CPAN RPMs

Today I’ve updated my spreadsheets of the CPAN modules that are available as RPMs from various repositories for Fedora and Centos. I see that in many cases the “official” repos are now more up to date than my own repo (which I originally set up because the official repos are sometimes out of date).

This is all a precursor to doing a lot more work on my repo. I need to know which RPMs are being kept up to date by other people so that I can ignore those modules.

But I thought that other people might find the data useful or interesting.

Three Short Announcements

Been a while since I’ve had time to post anything here, but I’ve just got time for three quick announcements.

1/ Last week I ran some public training courses. I’ve just put the slides online.

2/ There’s a London.pm technical meeting in two weeks time. It’s at Net-A-Porter (above the Westfield shopping centre) on October March 10th. A good line-up of talks. If you’re interested, please sign up.

3/ I was going to explain how the context examples in my last post worked. If you haven’t worked it out yet, I recommend a close read of the documentation for reverse.