Perl strategy for a new Snow Leopard user? [closed]

Question

I'm about to get a new iMac. It's my first Intel mac and will presumably come with Snow Leopard. What would other users recommend as the right strategy for installing and using perl on this machine?

I know I've read some complaints about the version of Perl (or was it the version of CPAN?) shipped with Leopard, although a quick google isn't coming up with much.

I'm assuming that a good strategy is to leave the system perl alone and install my own, but what would you use? Fink, Macports, maybe XAMPP for Mac?

Are there any particular gotchas for someone who hasn't used Perl on Intel macs before?

I'm not exactly a power developer, but I have quite a few utility scripts and MySQL database applications which run on my old machine I'm going to want to keep, and my main work is web development.

Answer 1

After many years of using Mac OS X and perl, I've come up with a simple three-part plan:

• Compile from source
• Install in /usr/local
• Never touch the system perl

Learn it. Know it. Live it.

…

Oh, alright, I'll try to explain. Touching the system perl at all is a bad idea for what I hope are obvious reasons. Apple's applications, third-party applications, and the OS itself expect the system perl to behave like the system perl—sometimes exactly like the system perl. To give just one example, at one point an iTunes installer included a perl script that contained code like this:

if ($foo EQ $bar) {
    ....
}

Yes, EQ rather than eq. Believe it or not, that actually works in many older version of perl—but not in the new version of perl I'd installed on top of the system version in my youthful naiveté. The result was that I'd double-click on the iTunes installer and literally nothing would happen. (And hey, it could have been a lot worse.)

We can talk about the kinds of monkeys Apple apparently had writing perl code back then (and wether the quality is any better now) but the bottom line is that /System is Apple's domain. Attempt no landing there. (How topical.)

On the other hand, Apple has a longstanding promise not to ever put anything in /usr/local, and just as importantly, not to touch anything that's there during system updates. This is your safe zone. Install your perl there, your libraries required by CPAN modules there, etc.

Finally, why build from source? Why not use a package manager? This may just seem like Grumpy Old Man reasoning, but I prefer to think of it as Hard-Won Wisdom. There is no one dominant package management system for Mac OS X, let alone an official/built-in one. All of the various third-party package managers come with the same problems as every package manager I've used: sometimes the software you want isn't packaged, sometimes it's not packaged the way you want it to be, sometimes it's just plain broken, etc. And trying to install packages in addition to building some software from source is a recipe for disaster.

The only viable "unified" approach is to build everything from source. These days, nearly all commonly used Unix software builds on Mac OS X without any special effort. (It helps that so many Unix developers now use Mac OS X as their personal systems.) It's usually just untar, configure, make, make install. You rarely even need to specify /usr/local as the destination; it's the default for most software.

So there you have it: Compile from source. Install in /usr/local. Never touch the system perl. You won't regret it.