Sam's Blog

First Impressions with Strawberry Perl

Date: Thursday, 15 July 2010, 12:10.

Categories: perl, ironman, strawberry-perl, windows, template-benchmark.

Thanks to a bug report by Adam Kennedy for Template::Benchmark, I found myself needing to do some testing on Windows this week.

Now to be clear, I've always loathed using Perl on Windows. I appreciate that some people use it, and I'm of the opinion that I should write my modules to work on it, but I'm happy to never touch it myself.

So it was with no small amount of trepidation that I downloaded Strawberry Perl for Windows.

Here are my first impressions.

The Download

Download was about as painless as you can get, visit strawberryperl.com, pick 5.12.0.1 from the prominent download link and save it somewhere.

(Try not to be blinded by the radioactively fluorescing strawberry while you do it though.)

The Install

Double-click the strawberry-perl-5.12.0.1.msi and you're away, and here's where I hit my first problem.

It wanted to install to C:\Strawberry\, and like most people using Windows since Windows 95, I like to keep all my applications in C:\Program Files\ rather than clutter up the root directory.

No such luck, I bluntly got told that it can't install to a directory with a space in it.

There's no doubt a good reason for this, I'm sure there's a million things that break and go wrong, or that could break and go wrong, or CPAN modules that will go berserk when there's spaces in the install path, include path, etc, etc.

I suspect this because I've been developing Perl for many years and have some appreciation of just how hardwired a lot of assumptions are that you're working on a semi-standard UNIX file-system layout.

I don't know it though, and if I was a newcomer I'd simply be left with the impression that either Perl or the installer sucked so badly that it "couldn't" install to a path with a space in it, which every Windows program for the past 15 years has been expected to do by default.

This is almost the first interaction some people will have with Perl and to start by blocking them from standard Windows behaviour... well they need to be sold on the idea.

Rather than bluntly prohibit them with no explanation, it perhaps should explain that it's doing them a favour by averting possible trouble in the future, something like: "Strawberry Perl asks to be installed in a path without spaces to ensure the widest range of compatibility with those CPAN modules that weren't designed with Windows in mind."

"Look we're being helpful" is a much better first impression to create than "Perl can't do basic Windows stuff".

Gritting my teeth somewhat already, I gave it permission to install to C:\Strawberry\ and it swiftly installed without further problem.

CPAN

So, I have Strawberry Perl installed, what now?

Well, I needed to test my modules, and to do that I needed to install them, so first port of call was "Start Menu > Strawberry Perl > CPAN Client".

Up pops something that looks distressingly familiar, it's the Windows command-line window, yay! OK, it's not the fault of Strawberry Perl, but damn I hate this thing with a passion.

Inside the window is the CPAN client however, and I quickly type:

install HTML::Template

And off it goes.

Yes, I didn't have to answer 500 questions before I started using CPAN, it just downloaded and installed HTML::Template without a fuss.

Score one for Strawberry Perl, CPAN worked out of the box with less hassle than even a UNIX install.

With that under my belt, I started installing all the various template engines that Template::Benchmark supports. (I really need to make a Bundle::Template::Benchmark or something someday... soon.)

Unsurprisingly, given that there's around 20 of them, a fair few died a fiery death during the install, but that all appeared to be due to those modules not playing nice with Windows, rather than Strawberry Perl doing anything wrong. A surprising number of the XS modules seemed to build fine, quite different from my ten-years-obsolete prior experience.

First Run

By this stage I have everything I needed installed to replicate the bug report, it was time for the tricky part... running the script that Template::Benchmark installs.

A quick "Start Menu > Strawberry Perl > Perl (command line)" later and I have another depressing DOS-window, opened somewhat ironically in the C:\Documents and Settings\illusori\ directory given my earlier ranting about spaces and filenames.

OK, this surely wasn't going to work, but I thought I'd try it anyway:

benchmark_template_engines -d 0 -r 1

At this point my jaw dropped open because, it worked.

Well, it didn't work work, it actually failed and spewed a bunch of error spam, but that was because of the bug I was trying to replicate.

It certainly ran the right script, with the right options, finding all the modules it was supposed to find and doing all the things you'd expect of a working Perl install, things that I was absolutely certain it wasn't going to manage.

Score two for Strawberry Perl.

Non-CPAN Installation

A short while later I've fixed the bug, and have my next problem... installing a non-CPAN module so that I can test before I upload to CPAN.

Well I copy Template-Benchmark-1.04_01.tar.gz onto the Windows machine and then discover that I can't just untar and do ./Build because... er, well my fault really, seems the context-menu unzip program I use does horrible things with .tar.gz files, so I don't even get to see whether ./Build would work or not.

Time to get creative, so I browse through to the CPAN cache and drop the file in as S\SG\SGRAHAM\Template-Benchmark-1.04_01.tar.gz as if it had been downloaded by CPAN, and then in the CPAN client type:

install SGRAHAM/Template-Benchmark-1.04_01.tar.gz

This mostly seems to work, but gives me some rather strange pop-up dialogs during the tests:

perl.exe - Unable to Locate Component This application has failed to start because libeay32_.dll was not found. Re-installing the application may fix this problem.

I suspect this is to do with some of the odd environment variable fiddling I had to do to get the script tests running on some smoke-tester configurations, and I think maybe those tests were skipped on the original install of Template::Benchmark because I hadn't installed the right template modules yet.

I've honestly no idea what it's about, or what libeay32_.dll is needed for, or by.

As it turns out, Adam Kennedy had helpfully informed me that I could have saved myself some bother and just done:

pip Template-Benchmark-1.04_01.tar.gz

To extract the tarball and build as a local module, without all the messing around trying to fool CPAN into thinking it had downloaded it.

The pop-up windows still come up during the test, but I'm fairly certain that this is something I'm doing odd that's interfering with Strawberry Perl's environment.

Shrugging that aside as a bug for another day, I've done what I set out to achieve: replicated the reported bug and tested the fix, using Strawberry Perl for Windows.

Conclusion

Aside from the niggles with the install path, and despite my hatred of the Windows command-line, Strawberry Perl seems to do an excellent job of "just working" on Windows.

I was particularly impressed by the way CPAN was easier to get running on Windows than my usual Debian install.

Strawberry Perl feels like a "proper" Perl install, it just happens to be on Windows, most issues I came across were due to individual modules not playing nice with Windows, with only my own tests seeming to cause any problems with Strawberry Perl itself (and given how much of a hack I've used there, I'm sure that's my fault.)

Strawberry gets the thumbs up from me, I now have a relatively painless way to test my modules on Windows and that's all I really needed.

Working from the command-line is always going to feel awkward in Windows, so I'll be interested to see what more GUI-friendly tools and integration of Perl can produce. Padre in particular seems like a good approach to using Perl on Windows, and one I keep meaning to investigate.

That however, is a project for another day.

Browse Sam's Blog Subscribe to Sam's Blog

By day of July: 01, 07, 15, 24.

By month of 2010: March, April, May, June, July, August, September, November.

By year: 2010, 2011, 2012, 2013.

Or by: category or series.

Comments

blog comments powered by Disqus
© 2009-2013 Sam Graham, unless otherwise noted. All rights reserved.