Perl strategy for a new Snow Leopard user? [closed]_问答_开发者

Closed. This question needs to be more focused. It is not currently accepting answers.

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

Improve this 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.

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.

If you're like me you will be installing macports anyway (I use it for mutt, colordiff, fetchmail+ssl etc), which means you will have ended up with a second perl in /opt/local/bin/perl, which will also result in a huge number of cpan modules being added to /opt/local/lib. These will be entirely separate from the system perl (installed into /System/Library). Since macports only installs perl 5.8.9 by default (at least, that's what I ended up with via dependencies after installing lots of macports distributions), and Apple is still bundling perl5.10.0 with 10.6.2, you will probably want to install a third perl (version 5.10.1), somewhere else. Now this is starting to get complicated...

See this question and particularly brian d foy's answer to How do you manage your Perl modules?. He discusses his strategies for installing multiple perls and managing its modules.

For me, I can't see a need for versions other than 5.8.9 and 5.10.1, so I simply downloaded/installed 5.10.1 from source directly into /usr/local/lib and /usr/local/bin (i.e. ./Configure -de -Dprefix=/usr/local), where my PATH uses the order /usr/local/bin:/opt/local/bin:/usr/bin. I will not make any modifications at all to the system perl: Apple will update components as needed for its internal systems. Furthermore, I will not make any (manual) modifications to the macports perl: new modules will be downloaded and installed via dependencies as I install new tools. The ordering of my PATH will ensure that the 'cpan' command will not touch these installs (unless I change some other config variables first). I will only use the version in /usr/local for my own development, and manage its modules via CPAN directly.

(I haven't installed fink on my new system yet, but if I do, I will manage it identically to the macports perl: keep it later in my PATH than /usr/local/bin, and it will only get updated via installation dependencies.)

Regarding the default system Perl breaking things, see

http://www.theregister.co.uk/2009/02/16/apple_update_perl_breakage/
http://discussions.apple.com/thread.jspa?threadID=1905157

IMHO, it's always a good idea to avoid the system perl on any OS and install your own. On MacOS X, I've always had good luck just downloading the source and compiling it. (This will require an install of the MacOS X Developer Tools to get gcc and whatnot; it's not installed by default.)

I just started using using local::lib with the system perl. So far, I'm pretty happy with it.

Follow the bootstrap instructions, then set environment variables to match local::lib output in /Users/blah/.MacOSX/environment.plist.

The default Perl coming with Snow Leopard is pretty good. It's v5.10.0. I've actually had less problems with it than the macports one (for DBI for example). I'd recommend sticking with the default Perl (and all other default programs) until you bump into something that doesn't suit you. No need to bother with newer version just for the sake of newer versions...