Good news are: if you like Windows, you can use it for Catalyst development (I wouldn’t use it for deployment, though).

First of all – Windows does NOT come with Perl. Really! And the same goes for Python and Ruby. Quite strange… but easy to overcome. There is a nice Perl distribution – Strawberry Perl – prepared especially for Windows. It has nice no-brain installer, so everything you have to do is to go the website and pick the version you like.

Yes, there are two. The only problem with choosing one is that while 5.10 is more modern and has some goodies, it may affect the ease of your Catalyst development – it is known as the “unknown error” bug. The 5.10.1 should be released soon, but at the moment 5.8.9 would be a safe bet.

Anyway, I assume you picked one, downloaded it, installed and you are ready to get Catalyst. It will require some tampering with command line, so get ready.

CPAN shell in action

First open the command line window and run the command perl -V. This will show you all the information about the installed Perl interpreter (see the picture – in my case it is 5.10.0 version, but the 5.8 should be very similar). When you are sure you have Perl installed on your system, go to the Start -> Programs -> Strawberry Perl -> CPAN client. You will get another command line window with CPAN shell running inside. It starts with downloading some bits of necessary information, chewing it and when it’s ready, it welcomes you with cpan > prompt. Now type

install Catalyst::Runtime

and press Enter. As your system is quite empty, you will have to install some packages Catalyst depends on. It takes some time and you may have to answer some questions or confirm some actions now and then. When this operations finishes you will be able to run Catalyst applications on your Windows machine.

CPAN shell asking for dependencies

But the point is to develop such applications. For this we need the Catalyst::Devel package, but before we go into this, we have to fight with some minor glitch. The problem is, that Template Toolkit installation breaks on Windows. It breaks only on building the XS module (the pure C backend, which is faster than the Perl one; we can sacrifice it, as on development machine we don’t need to be blazingly fast), and the good news are, that we are asked if we want to use it, and we can say “no”. However the bad news are, it tries to use it during the test phase of the installation, then fails, and then refuses to install.

So, my suggestion is to overcome it that way:

cpan > force install Template

Now we will be able to install it even if tests fail. Use it sparingly, cause most of the time tests should determine if package is ready to be installed, and passing the test suite is a good measure for this readiness. Also remember to answer “no” while being asked for XS – otherwise the build process will break and even the force option won’t help.

Catalyst::Devel asking about 'unknown bug'

After that we are ready to finish the installation:

install Catalyst::View::TT

install Catalyst::Devel – if you decided to use 5.10, remember to answer yes for the “unknown error” question (default is no) Update: I checked it on Strawberry Perl 5.10.0.5 (from April 2009) and it is not fixed in this version

Now you are ready to begin your adventure with Catalyst on Windows. You have to remember two things, though:

use catalyst.bat instead of catalyst.pl for creating your application

while using the scripts created by Catalyst, like script/myapp_create.pl or script/myapp_server.pl, you have to specify that they should be run as under Perl interpreter, so you have to use the perl script/myapp_server.pl

don’t use script/myapp_fastcgi.pl – at the moment there’s no easy support for running Perl webapplications using FastCGI on Windows

That’s all. The 99% of the Catalyst development should be OS agnostic. And every other Perl module you would need can be installed using CPAN shell. Enjoy!

Since one of the goals of Strawberry Perl is not to patch Perl itself, the “unknown” error bug isn’t fixed in any of the 5.10.0.x versions. It SHOULD be fixed in the 5.10.1.0 version that will be released next month, and is currently in beta now.

alexsaid

Brett Gsaid

I did not have to force install Template. I assume that is because the issue with XS has been resolved since the blog was written. I went ahead and answered YES to the questions re: using XS (one re: whether to install, one re: whether or not to use XS by default).

Also, if you’re using MySQL, be sure that you use double-quotes in your model create statement. If you’re coming from another OS, you may need to (first back-up, then) delete your lib/myapp/model, and lib/myapp/Schema folders along with your lib/myapp/Schema.pm file.