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

[Tomas Doran]

On 26 Feb 2010, at 01:34, Toby Corkindale wrote:

> 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.

Conceptually, deploying a Catalyst app as a PAR is a great idea.  
Practice however is somewhat different :(

>>
>> 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.

Just so. In fact, it won't find everything you declare in Makefile.PL  
(just the things found when perl -c ing your app). It will also  
miss .so (system shared library) files that might not be on all systems.

Common examples being libexpat, libxml2 and libssleay - there are  
loads of others :)

> Eg. Building a catalyst_par for a fastcgi-based app is broken out of  
> the box. (It doesn't pick up Catalyst::ScriptRunner)

Patches to require the appropriate modules in Catalyst.pm so that  
Catalyst does work out the box would be welcome.

I tried to fix this (and made a branch which you'll find in our svn),  
but this just made PAR shit itself on my mac, and given I'm not a PAR  
user and nobody else was showing any interest, I gave up.

If there is an active PAR user out there who would like to get this  
fixed - come chat to someone in #catalyst-dev, as that can totally  
happen.

> 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.

Quite..

> 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.

Oh yes - DB libraries, more fun :)

> 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?

The other option? :)

> 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.)

Depends which debian you consider the one true version.

The debian perl guys++ recently, as they've put in a lot of work to  
get debian updated to the latest Catalyst and recommended modules.  
AFAIK 5.80 is still only in 'unstable', but that's still totally  
reasonable given that 'stable' in debian terms usually translates as  
'antideluvian'. :)

> 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.

That's totally fair. There's a middle road here of course - if you can  
standardise on 'an os' at a time, as long as it's not deadrat then  
'system perl' isn't so bad (as long as you use Task::Weaken <cough>)...

And with local::lib per-app perl modules are easy to ship around.. And  
of course you can keep your local::lib in git etc..

So generally personally I tend to try and use the perl which is there,  
and build per-app CPAN stacks..

Cheers
t0m