The command line installer adds files to the traditional /usr/local directory, while the MacPorts package manager adds the files to /opt/local.

And from there, troubles arose.

The truth is, I’d forgotten about the /usr/local pear install, until I’d noticed something peculiar trying to setup a Symfony project I’m working on. Attempting to run one of its command line tasks, I got a fatal error from PHP, reading:

  [#!shell]
  $ ./symfony cc

  Warning: require_once(/opt/local/lib/php/symfony/autoload/sfCoreAutoload.class.php): failed to open stream: No such file or directory in /Users/yanni/Sites/Hosts/breadbreaker.dev/config/ProjectConfiguration.class.php on line 3

  Fatal error: require_once(): Failed opening required '/opt/local/lib/php/symfony/autoload/sfCoreAutoload.class.php' (include_path='.:/opt/local/lib/php') in /Users/yanni/Sites/Hosts/breadbreaker.dev/config/ProjectConfiguration.class.php on line 3

The file paths for the require statement in the ProjectConfiguration.class.php file were generated on my home computer, which was configured to use the MacPorts pear, which installs Symfony at /opt/local/lib/php.

So I thought to check which pear installation I was using:

  [#!shell]
  $ which pear
  /opt/local/bin/pear

Huh. That’s… actually (correctly) the MacPorts one. Next, I thought to check where my Symfony package was installed:

  [#!shell]
  $ which symfony
  /usr/local/bin/symfony

“Ah!” I thought with relief at the promise of closure, “It’s using a version of Symfony I’d installed before I’d installed MacPorts’ pear.” Then I thought I’d confirm that I still had the old version of pear laying around:

  [#!shell]
  $ find /usr/local -name pear
  /usr/local/bin/pear
  /usr/local/share/pear
  /usr/local/share/pear/pear.old/symfony/plugins/sfPropelPlugin/lib/vendor/propel-generator/pear
  /usr/local/share/pear/symfony/plugins/sfPropelPlugin/lib/vendor/propel-generator/pear

I’d found it. I only wanted to keep a single version of pear libraries on my system (under MacPorts), so I proceeded to uninstall the Symfony package from /usr/local and install it explicitly into MacPorts’ own /opt/local.

  [#!shell]
  $ sudo /usr/local/bin/pear uninstall symfony/symfony
  uninstall ok: channel://pear.symfony-project.com/symfony-1.1.3

  $ sudo /opt/local/bin/pear install symfony/symfony
  downloading symfony-1.2.8.tgz ...
  Starting to download symfony-1.2.8.tgz (2,695,461 bytes)
  ..........................done: 2,695,461 bytes
  install ok: channel://pear.symfony-project.com/symfony-1.2.8

I then proceeded to confirm that Symfony was now installed somewhere within the /opt/local directory branch:

  [#!shell]
  $ which symfony
  /usr/local/bin/symfony

It wasn’t. I then tried to rename the pear files in /usr/local so that they wouldn’t be found, but that didn’t work either. I Googled far and wide, and found my lead in the Pear Documentation website’s article about shared hosting.

I had configured my .pearrc file to explicitly look for installed pear libraries in /usr/local. This setting was even being honored by the pear in /opt/local.

I renamed my ~/.pearrc file to ~/.pearrc.old and attempted to install the Symfony package again. Pear complained about an unknown installation source, which meant I had to “discover” Symfony’s pear channel. Once I’d done this, Symfony installed to the correct location!

Finally, I just dumped the old pear installation under /usr/local and the file now named ~/.pearrc.old, and was fully transitioned to the MacPorts pear.

How do you like them apples?

Lessons

• Ensure that you’re executing the correct pear script (on Unix, use which to determine absolute path of the script being used)
• Verify that your php.ini file has got the correct pear installation path in its include path.
• If you encounter some wonkiness with the inclusion of pear libraries, make sure there isn’t some .pearrc file with vestigial configuration settings messing with you.

Because of the flexibility it offers, there are several ways a particular enhancement or customization can be added to the system, and you are free to pick the one that best suits your needs or preference. The ensuing burden of this flexibility, however, becomes a responsibility on your end to mind just how you added each enhancement or customization, in case you later need to adjust it.

While you’re naturally free not to track such details, this practice guarantees that you’ll spend as much time trying to “re-figure-out” that clever enhancement or customization you figured out how to apply in your own special way.

History has taught me that any of these clever enhancements and customizations will eventually need revisiting. It’s inevitable… like destiny, except less romantic.

In this case, I recently picked up a new MacBook Pro.

Its name (configurable via System Preferences > Sharing > Computer Name) is Syggrafeus because its primary use is for writing. As a point of whimsical fact, I have a nerd-confession to share: I name all my computing devices that support unique names. I also confess that I never reuse any of these names.

Syggrafeus replaces both the HP Mini 1120 Linux netbook I tried out in the spring (which, since I’m mentioning names, I’d named Astinus), and a 2.5 year old MacBook Pro, named Forty six and 2.

Both of these older computers were to be wiped clean, as they were each to have new owners, so I had to move data from each to Syggrafeus.

From the netbook, I had only some text files I wanted to keep; mostly some unfinished Uncarved pieces. That was easy — a small USB flash drive did the trick.

Forty six and 2, however, had a whole slew of files I wanted to preserve, including user settings, passwords, software, and more. Luckily, Mac OS X comes bundled with an application called Migration Assistant, which is designed to allow you to move from an old Mac to a new Mac as quickly and effortlessly as possible.

Migration Assistant does an astonishingly thorough job. This is, at different times, either wonderful or maddening. Sometimes even both at once.

In my case, it copied all sorts of software over from my old system, as well as preference and configuration files. That’s largely just awesome, since it saves a heap of time. It’s the fastest way to get started using your new Mac out of the box, period.

There are, however, some tradeoffs to this convenience.

Things evolve over time. There are some enhancements and some customizations I’d like to accomplish in ways that differ from what was ideal 2.5 years ago. In some cases, newer software or tools exist that absolve me of having to use my own (or some obscure Internet stranger’s) clever personal tactics. In other cases, I’ve learned more practical or efficient ways to accomplish things.

And so, born from this, I have decided to begin a series of HOWTO posts that will attempt to explain how to accomplish various system enhancements or modifications, while attempting to account for potential vestigial artifacts that can interfere with the process.

The series will be called Tabula Quasi-Rasa, since I’m hung up on the idea that using dead languages is somehow fun or clever.

The posts in the series will assume an entirely geeky audience, since non-geeks are almost entirely unlikely to ever even run up against such concerns. The first few posts will cover my adoption of the MacPorts package manager (formerly Darwin Ports) in lieu of the practice of installing software in the traditional /usr/local directory.

In any case, it is my intent to both compile a collection of notes for myself as well as that they might save a person or two an hour or two.