[Catalyst] on the topic of PAR file distribution, why is it frowned upon?

[Toby Corkindale]

On 26/02/10 11:27, Tommy Butler wrote:
> Hello all,
>
> I will be deploying a catalyst app onto several dozens of servers in the
> next months, which will probably turn into more than that eventually.
> It is a year in the making, and quite complex in terms of all the things
> it requires to run (libraries).
>
> Given that, a PAR distribution file seems like a great way to go.  Yet
> my co-worker told me that this has been frowned on as of late-- that
> there has been a shift in opinion about deploying cat apps as PARs.
>
> What's the downside of this?  How is this going to pose a problem for
> me?  Installing from subversion and then CPANning all the required libs
> into the system via the makefile is terribly slow and error prone.
> There's an obvious negative there.  What's the negative with using PAR
> when compared to this other method of deployment?

The main problems are that PAR doesn't actually work very well.

Firstly, it is severely broken on perl 5.10.0, so you'll either need to 
stick with perl 5.8.x or go to perl 5.10.1. (Or backport fixes from perl 
5.10.1 to .0, but there lies insanity.)

Secondly, PAR is a nightmare. It's meant to automatically locate all 
your dependencies, but in practice this never finds all of them.
Eg. Building a catalyst_par for a fastcgi-based app is broken out of the 
box. (It doesn't pick up Catalyst::ScriptRunner)

So you'll need to go through a long cycle of
  * build par
  * attempt to run it, and discover which modules are missing
  * add those modules to list of extras
  * Repeat. A lot.

You'll also need to explicitly list all the /var/lib/* things you need, 
like libpq.so, libxml.so, etc as those aren't picked up.. and all their 
dependencies manually too.


I really don't like deployment methods that are based on 
trial-and-error. It doesn't give me any confidence that we did manage to 
find all the extra modules to list as inclusions.. and so you can bet 
that there's one more missing, that won't be discovered until your app 
is crashing in production.


So, there are some negatives for PAR.
The question is, do they outweigh the negatives for using CPAN to 
install random, latest-and-possibly-broken packages via the Makefile 
every time?


Some shops have a rule that you must only use the versions of modules 
that are available pre-packaged for the operating system.
This gets around the problems of having to install everything by hand, 
and also means you get consistent versions of modules..
However it also means you're stuck with a small subset of CPAN, and 
usually very old versions as well. (For eg, Debian is still on Catalyst 
5.7 I believe.)



My own solution was a fourth option:
Build your own Perl, and all the required modules, installed into a 
custom directory - and then ship this with your application.
It'll blow the size out by a hundred meg or so, but at least you know 
it'll work, and it's using known-good versions of CPAN modules.



-Toby