====== Installing Perl Web Apps ======

===== Ideal installation process for web users without shell =====

  - Download zip file
  - Unzip it
  - Optionally, edit a config file
  - Upload to a website
  - Optionally, point browser at install/initialisation script

===== Ideal installation process for experienced Perl users with shell =====

  - Install CPAN module
  - cd into a directory and run foo-install
  - Optionally, edit a config file
  - Optionally, point browser at install/initialisation script

===== CPAN pre-requisites =====

Assuming a typical web hosting provider, you can assume that the following Perl modules are available:

  * Core modules (but which Perl version?)
  * DBI, DBD::Mysql if the hosting provider offers MySQL

Other than that, you're going to have to roll dependencies into your package.


===== Binary pre-requisites =====

Any CPAN module which requires compilation will be a complete PITA to distribute.  The two options are:

  - Package binaries
  - Go for pure perl alternatives (even if that means writing them)

One problem with packaged binaries is that J Random Web User doesn't know whether his webhost is Linux, BSD, or what.


===== What about databases? =====

Most web hosting providers have MySQL.  If an app needs a database, you can say "MySQL is a pre-req" and generally assume that a goodish bunch of people will have access to it.  Furthermore, web hosts who have MySQL generally have DBI and DBD::MySQL installed already.

DBD::Mysql_PP (Pure Perl) might be worth looking into.

SQLite *might* be worth looking into, but would require compiled libraries (DBD::SQLite is XS), and I've experienced weird version mismatch problems on DreamHost, so that might be a commonish problem.

PostgreSQL and other databases, while lovely and having a strong following among the geek cognoscenti, aren't really a big target for mainstream web apps.  I suppose you could make your app use it as an option, but it's not something you'd package for general use.



===== What about mod_perl, FastCGI, etc? =====

I reckon any Perl web app that wants broad distribution needs to run under plain old CGI, with FastCGI as a second option and mod_perl as a third.

Some webhosts (eg Dreamhost) offer FastCGI as a simple checkbox-click option for web hosting, so I imagine that's reasonably common.  Web hosts that offer mod_perl are, I think, few and far between.  Not common at a consumer level, anyway.

With regards to performance issues, some high percentage of J Randoms won't need it.  They're going to blog about their cat, or set up a CMS for their local PTA.  Even something like http://cuteoverload.com/ which I imagine gets a fuckload of traffic would probably be OK as CGI on most hosting providers, as long as it's not spiky.  And if you get dugg... well, you're probably up shit creek anyway, unless you're using Coral Cache or something.  I know that my Wordpress (PHP) blog, with caching enabled, was still spiking the load up to 20 on Dreamhost's servers when I got dugg.

===== Upgrade path =====

We need to think about upgradability as well as installability.

(Uninstallability can presumably be managed by rm -rf webdir/ if the installation is as described.)

===== Local customisation =====

Along with upgradability there are issues around local customisation.  Simple example: say you have a config.yml file which is installed with the initial distro.  You edit it to add your own database connection details or whatever.  Then when you upgrade, the new version has additions to config.yml.  How do you merge in the new additions without overwriting the local configuration changes?

===== Possibly useful modules =====

  * PAR
  * Module::CGI::Install
  * App::Bootstrap
  * Archive::Builder

===== Existing installers =====

  * kwiki-install
  * minimvc-install
  * catalyst.pl
  * bryar-newblog
  * module-starter