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
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
