CPAN and the Installability Crisis

Posted on by

How do you install a PHP web application?

Generally it goes like this:

* Download zip file
* Unzip on your PC
* Edit a config file
* Upload to your web host
* Point your browser at `install.php`

How do you install a Perl web application?

Well, it depends, but a lot of them go like this:

* Login to your shell account on your web host — assuming you’ve got one
* If you haven’t done it before, make sure your CPAN config knows to install in your homedir — either by answering the initial config questions, going through a fiddly process with `o conf` in the CPAN shell, or editing the `.cpan/CPAN/MyConfig.pm` file
* `perl -MCPAN -e Some::Web::App::Framework`
* Pray that all the dependencies install clean; chances are that you’re going to have to force some of them. Be prepared to jump out into `.cpan/build` and install manually if things go awry.
* Go digging round in `.cpan/build/Some-Web-App-Framework-1.23/examples` — if the author’s been kind enough to provide a clear example. Otherwise, glean it from snippets in the documentation, or go googling for sample code.
* Copy the example into your website directory
* Edit the results to suit your needs

If you’re lucky, that editing is just a matter of library paths and database connection details. If you’re less lucky, the example code reads something like:

package My::Web::App;
use base ‘Some::Web::App::Framework’;

# customise your web application here

Erk.

Here’s what I’ve come to realise

* CPAN is *fantastic* for distributing libraries and frameworks for programmers to use.
* CPAN is *not too bad* at distributing standalone command-line Perl scripts, provided they’re associated with a module.
* CPAN is generally *terrible* at distributing full-blown, ready-to-use applications.

The result of this is that if you want to build your own custom web app, Perl is great. But turning your custom web app into a distributable application is hard, and chance are you won’t bother. And if you just want to *install* a ready-to-use blog, CMS, or shopping cart, you’re probably going to end up using PHP.

That makes me sad.

Luckily, there are a few efforts underway to help with the problem. I haven’t seen anything that’ll make things as easy as your typical PHP app, yet, but the building blocks are starting to be put in place. Here are a few of the puzzle pieces I’ve encountered recently:

* PAR is meant to provide a Perl equivalent to Java’s “JAR” file format: a single archive of an application and all its related libraries.
* Module::CGI::Install is an installation toolkit for web apps. If you have created a web app that runs under CGI and is distributed on CPAN, you can make it easy for end-users to install instances of the web app using `cgi-install Web::App`. It asks them where they want the CGI scripts, static files, and so forth, and puts the files there for them.
* App::Bootstrap is something I whipped up tonight; one of my favourite Perl web apps, as far as installation is concerned, is Kwiki. It comes with a script called `kwiki-install` which vomits out everything you need for a wiki in the current directory. App::Bootstrap makes it easy to write that kind of `foo-install` script.

As far as I can see, the missing link at the moment is that PAR assumes that you *don’t* have a shell account or the ability to install stuff off CPAN, and the two installers I mentioned assume that you *do*.

I suspect that what we’re going to have to do is offload the responsibility onto the application developer, and give them a good toolkit so that they can create a simple, ready-to-use installation using one of the installer-style scripts, then bundle it up — along with all its library dependencies — using something like PAR*.

* A PAR archive, incidentally, is just a renamed zipfile. So as far as I can tell, you could create something with PAR and then `mv foo.par foo.zip` and it would be extractable by the average user.

9 thoughts on “CPAN and the Installability Crisis”

  1. A PAR archive, incidentally, is just a renamed zipfile.

    So is a JAR. Except one of the files in the JAR is a MANIFEST. I use unzip tools all the time on JARs. It’s very handy because jre (Java Runtime Environment) doesn’t have the “jar” command.

  3. You’re clearly suffering from a missing and/or broken package management system. CPAN IMHO is mostly targeted for developers.
    So construct your {Build,Makefile}.PL, add the correct dependencies and build a package for your operating system. Done. Never ever fight again with wild dependency stuff.

    It’s just a question of organization – don’t make existing technical solutions responsible for design problems.

  4. Simon: And you’re obviously suffering from always having root on systems you work on. The vast majority of people with websites run them on cheap hosting where they can’t simply install packages for the OS. Most of them don’t even know what OS their hosting providers use.

    I assure you I’m fully cognizant with the use of package management systems — we set up a really sweet system with dh-make-perl and our own apt repository at one of my recent workplaces — but they’re just not relevant when it comes to deploying mainstream web apps for the average joe.

  5. I’m pretty sure I’ve convinced CPAN to install in my ~/perl directory as a user. It’s been a while, and I can’t remember how.

  6. Paul: Oh, absolutely. I do that myself on Dreamhost. But you do need shell access, and it’s a little fiddly, both of which are barriers to entry if all you want is a working blog/wiki/cms/whatever.

    (Step 2 in my post, “If you haven’t done it before, make sure your CPAN config knows to install in your homedir” etc, refers to this.)

  9. You can use PAR::Dist::install_par to install a .par to some user-local place. It’s basically a wrapper around ExtUtils::Install, so one needs to set a couple of directories oneself. I wrote a more user-friendly installation script for bugzilla in the following ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=385304

Comments are closed.