[tpm] RFI: Installing Catalyst::* and all dependencies on WinXPPro , has anyone succeeded / failed? It looks huge
stuart at morungos.com
Mon May 31 10:23:31 PDT 2010
On 5/31/2010 12:52 PM, J Z Tam wrote:
> This Catalyst::* package space looks huge and I don't have high confidence in WindowsXPPro. So if someone's got the cheatsheet for known-working WinTel platforms, please share tips, traps, gotchas.
> TIA /jordan
Yes, it does work well, even on XP/Windows. I use a MinGW self-built
Perl, and I removed fork(), which means I get a few test errors from
some of the Test::WWW::Mechanize stuff, but I usually force those
modules. Here are a few thoughts.
1. Strawberry Professional should have all (most of) you need, so that
might be an option
2. Catalyst is very dependent on Moose, if you can't get Moose running,
then you can forget Catalyst
3. If you get that far, try installing Catalyst::Runtime - yes there are
many dependencies but most are simple and reliable.
4. The rest depends on which components you use. I tend to use
Catalyst::View::TT, Catalyst::View::JSON, Catalyst::Model::Adaptor, and
Catalyst::Model::DBIC::Schema. These will need DBI and a DBD, but that's
enough for a minimal application.
Traps: a few test errors might well happen on Windows and I tend to
check the code and judiciously ignore issues that appear not to be
relevant. Having said that, I've managed to compile Perl and built
Catalyst on it four times, ranging from 5.8 to 5.12, and it's all been
fairly straightforward in the end. We have far more problems with XML
parsers and other stuff.
We're working on 64-bit. The MinGW64 build does kind of work, but needs
more stability. So for now we're sticking with 32-bit stuff.
The other "gotcha" is hosting. We use FastCGI on IIS in production,
mostly because our clients insist on it. This is possible, but IIS has a
few issues. IIS5 doesn't work great yet, and I have a patch for this,
but haven't had a chance to test it on IIS7 before committing into
Catalysrt::Runtime. IIS6 works well, but you'll need the C/XS module
FCGI for that.
Catalyst does have a start-up lag on Windows. Normally, you would use
preforking on UNIX systems to cache a prepared process. Windows emulates
fork() and I've not tested this out that well. I'd be nervous about this
on Windows, but using multiple worker processes works fine for FastCGI.
Once your processes are started, Catalyst's performance is really pretty
good - even on Windows.
The Catalyst mailing list is good but a little twitchy, especially if
people ask questions really belonging to DBIx::Class (which is really
underneath Catalyst::Model::DBIC::Schema). They like people prepared to
contribute, but are very sensitive about criticism.
The positive: where I worked used to use ActiveState and it's "PerlEx"
crappy clone of Apache::Register/mod_perl. FastCGI works *very* well for
us, giving us very reasonable performance, even considering a lot of
hosting options (e.g., preforking) are not anything like as easy on
Windows. As a previous Java+Spring user, Catalyst has a very similar set
of advantages, and has been invaluable upgrading an old system, as we
managed to embed legacy components by wrapping them.
All the best
More information about the toronto-pm