Ouch!

Leon has a huge amount of experience with the module building tool chain, so normally he is someone I’d like to be paying attention to. And in one way he’s right – my understanding of EU::MM is very superficial.

However, calling Makefile.PL in this way works, and works well. I’ve installed over 100 modules with exactly this incantion.

It works for XS modules too. I’ve installed plenty of XS-based modules including DBD::[various stuff], JSON::XS, Starman (including its XS dependency…) and heaps more.

In all cases, make all test install worked just fine. Perl and XS built, tests run successfully and everything installed in exactly the right place. What’s not to like?

Thanks to Joel and Rick for the constructive suggestions.

• Production Perl code must run under the vendor supplied Perl
• Sysadmins will not install or upgrade Perl modules
• We are allowed to install any module from CPAN

The two production platforms we target are RHEL5.5 for which vendor Perl is an uncomfortable 5.8.8 and RHEL6.2 which has a much more comfortable Perl 5.10.1.

Our development boxes do not have access to the internet proxies which makes things a little more difficult than they should be.

David Golden lists 5 ways of installing module prerequisites here.

Installing Perl Modules – Method #6

The method I use, given the constraints above is to discover the prerequisites by running Makefile.PL (or Build.PL) and download the prerequisites by hand recursively.

This approach is straightforward once you have the correct Makefile.PL incantation.

PERL_LIB="$HOME/lib/perl5"

perl -I$PERL_LIB Makefile.PL PREFIX=$PERL_LIB LIB=$PERL_LIB PERL="/usr/bin/perl -I$PERL_LIB"

Note: You could set/override environment variable PERL5LIB instead of adding the -I arguments which is probably better, but aesthetically, I prefer the version above.

The executive summary:

• Roles are semantically safer than multiple inheritance because methods from the roles are loaded into the class at compile time and any name clashes are picked up then.
• Roles cannot be instantiated.

I’ve never seen anyone say that Perl is a superior programming language to Python, because of limited lambdas, deliberately restricted recursion or anything else.

Good humoured ribbing aside (depending on where you sit I guess), I believe that Perl and Python sit at approximately the same level on the language power continuum. I mean, they’re similar enough to be two different people’s take on the same underlying language (I kid, I kid!).

I do think that Perl is strictly more powerful than Python (with e.g. parser flexibility, symbol-table hackability). However, in most cases this additional power isn’t something you need. The main places I can think of where it has been used legitimately is where stuff that is built-in to Python has been added by Perl at the library level.

• Stevan Little writes about porting Bread::Board to p5-mopp5-mop
• A follow-up from Zak on porting Hashids

An aside… in my industry, we’re probably not going to be seeing any of this until 2020 or so. We’re still stuck on 5.10 (RHEL6).

Just when I was thinking about web apps another relevant post pops up on Ironman.

So far I’ve got notes on Perl and necessary modules.

• Strawberry Perl
• DBI and DBD::SQLite
• Plack and Mojolicious or Dancer
• AnyEvent and Twiggy ?

I’m planning to remove MinGW / and the compiler to make the final package smaller.

Here is the list of installation software.

At the moment I’m leaning towards NSIS for no particular reason.

What I’m thinking is that the installation script will check for the existence of C:\Strawberry. Then it will run the Perl it finds there.

• If it can’t find the directory, it can install it.
• If the directory exists and the Perl is good, use it.
• If the directory exists and the Perl is not good, abort with an error message.

Any input welcome.

IPC::ConcurrencyLimit is a handy module for implementing a number of concurrency patterns.

Steffan Mueller mentioned it in a comment on my blog back in 2011. Since then, there have been a couple of articles about it on the Booking.com dev blog

• Highlander
• Writing Advanced Daemons That Aren’t Daemons

• The point about a more mature version of a language failing vs an earlier version can’t be right. For example, if Perl 4 and Perl 5 were released at the same time, which would people choose?
• On the other hand, obviously Perl 5 would not exist, because of the lack of evolution, if it hadn’t been for Perl 4. I think I saw a speech by Larry where he said he had tried to lay grass down (e.g. symbol table hacking) for others to turn into sidewalks (e.g object orientation).
• Perl 5 is nicely designed for evolution. Take the Try::Tiny module for example. How many commercially acceptable languages could you add Try/Catch/Finally too if it wasn’t already baked into the language?