If you’ve seen me giving my “Kingdom of the Blind” lightning talk this year, then you’ll know that I’ve been hanging around places like the LinkedIn Perl groups and StackOverflow trying to help people get the most out of Perl. It can be an “interesting” experience.
One of the most frequent questions I see is some variant of “I have found this program, but when I try to run it I get an error saying it can’t find this module”. Of course, the solution to this is simple. You tell them to install the missing module. But, as always, the devil is in the detail and I think that in many cases the answers I seen could be improved.
Most people seem to leap in and suggest that the original poster should install the module using cpan (advanced students might suggest cpanminus instead). These are, of course, great tools. But I don’t think this is the best answer in to these questions.
In most cases, the people asking questions are new to Perl. In some cases they don’t even want to learn any Perl – they just want to use a useful program that happens to be written in Perl. I think that launching these people into the CPAN ecosystem is a bad idea. Yes, eventually, it would be good to get them using perlbrew, local::lib and cpanminus. But one step at a time. First let’s show them how easy it can be to use Perl.
In many of these cases, I think that the best approach is to suggest that they use their native package manager to install a pre-packaged version of the required module.
Yes, I know the system Perl is evil and outdated. Yes, I know that they probably won’t get the latest and greatest version of your CPAN module from apt-get or yum. And, yes, I know there’s a chance that the required module won’t be available from the package repositories. But I still think it’s worth giving it a try. Because in most cases the module will be there and available as a recent enough version that it will solve their immediate problem and let them get on with their work.
There are three main reasons for this suggestion:
- People in this situation will almost certainly be using the system Perl anyway. And the system Perl will already have pre-packaged modules installed alongside it. And installing modules using
cpanminusalongside pre-packaged modules in the same library installation is a recipe for disaster. The package manager no longer knows what’s installed or what versions are installed and hilarity ensues. - The pre-packaged versions will know about non-Perl requirements for the CPAN module and will pull those in as well as other required CPAN modules. One of the most common requests I see is for GD or one of its related modules. Your package manager will know about the underlying requirement for libgd.
cpanminusand friends probably won’t. - The user is more likely to be used to using their package manager. Teaching them about the CPAN ecosystem can come later. Let’s ease them into using Perl by starting them off with tools that they are familiar with.
I know that both Fedora/Centos/RHEL and Ubuntu/Debian have large numbers of CPAN modules already pre-packaged for easy installation. Let’s suggest that people make use of this work to get up and running with Perl quickly. Later on we can show the the power and flexibility that comes with using the Perl-specific tools.
Of course there’s then a debate about when (and how) we start to wean these people off of the system Perl and pre-build packages and on to perlbrew/cpanminus/etc. But I think that having a community of people who are used to using CPAN modules (albeit in this slightly restricted manner) is an improvement on the current situation where people often avoid CPAN completely because module installation is seen as too difficult.
What do you think? Are there obvious errors in my thinking?
Hm… it might be nice if perl’s missing module errors tried to offer some system specific advice, like have you tried “apt-get install perl-missing-module”?
I have a few caveats with what you’re saying, but I’m glad to see someone inside perl looking at it as it must seem from the outside. Too many of the gods of perl forget that not everyone is a rock star such as themselves, and there are people out there living completely different technical lives than they are.
One caveat is that many people are not in control of root access, and for them, doing an “apt-get install” may be a political hassle not worth bothering with. That’s the sort of situation that cpanminus handles fairly well (in the short term, at least).
That sort of thing leads to the conclusion that there’s really no one-size-fits-all piece of advise you can give people. And even after asking about particulars, for me at least, there’s limits: I can tell someone how to find a debian/ubuntu package, but I’d do less well on a “yum” based system, and have very little clue how the Strawberry/Activestate people get by on Windows. One virtue of cpanminus is that it’s one piece of advice you can give to everyone (or at least I think it is…).
I can’t say that running a “mixed” perl installation (system packages plus CPAN.pm installs, usually) has caused me a lot of trouble… it typically seems to Just Work (but then, it could be that’s just because I know how to setup my PERL5LIB right).
I ran into a mildly embarrassing problem at work recently, where the servers are all on a shared network file-system, and my old cpanminus installation left me with some perl modules compiled for a stale perl… I’d log-in to a different machine, get a new perl version, but still have the old cpanminus installs sitting in my PERL5LIB.
Unless “they just want to use a useful program that happens to be written in Perl”, I would suggest to teach them how to get them up and running on their nice iMacs and MacBooks, in their own user directories.
As a not so long ago Perl beginner, I love the idea how Ovid starts of his book with installing perlbrew. ‘The Gory Details’ is not what newcomers want to know. Having the right tools at your disposal is so crucial to quickly solve problems.
And you are totally right about your 2013 mission ‘Kingdom of the Blind’. Too many people give horrible answers and I will try once in a while tho bring some guidance, even though I have only little understanding myself.
http://deb.perl.it/ provides a nice way to find out if a CPAN module is available for Debian-based systems (and under what name!)
Your reasoning seems correct to me.
What would help is a call to action of seasoned Perl users to join the maintainer ranks of various distributions. And support them to offer up-to-date and more complete CPAN packages.
We certainly encourage that in Debian! Get started at http://pkg-perl.alioth.debian.org/
I agree that users should first try to use their native package manger first.
Even before that, if they are using a company computer, they should ask their system administrator to install the package. One issue we come across at my work is that people end up installing different versions of modules on their workstations than what ends up in production and headaches ensue (These issues are more apparent in R and Python than in Perl, in my experience). Best to get the sys admins involved so that everyone is using a uniform environment.
… it depends … If you’re starting a medium-to-large perl application start with perlbrew and cpanm. For system stuff the system perl will get you so far, but plan for a transition to perlbrew later.
I’m pretty sure that’s just paraphrasing what I wrote 🙂
I’m only talking about the recommendations that we should be giving to people who are just starting out with Perl.