It’s not supported on OS X.

But OS X is UNIX-y! There’s a version for Linux! Why won’t it work on OS X? Can’t you google for installation instructions?

Well, no. Perhaps my google-fu is weak, but I could find no information whatsoever about how to get it working.

In fact, if these guys hadn’t pointed out that it was possible, I would have given up then and there.

But I got it installed. And you can, too. Here’s how:

1. Make sure you have the Apple Developer Tools installed.
2. Download the Payflow Pro Java SDK (you have to log into a Payflow Pro account to get the download), and unzip it to your hard drive (it doesn’t matter where, as long as it’s a place where the user your web server runs as can get to it).
3. cd into the java directory.
4. Set your paths. I had trouble getting these to stick, so I’d love any suggestions anyone might have on that aspect:

   $ CLASSPATH=${CLASSPATH:-}:Verisign.jar:.;export CLASSPATH

   $ libpath=.:../jni:../lib

   $ LD_LIBRARY_PATH=$libpath:${LD_LIBRARY_PATH:-};export LD_LIBRARY_PATH

5. Compile the java code:

   $ javac PFProJava.java

6. Run a test transaction:

   $ java PFProJava test-payflow.verisign.com 443 "USER=YourUserName&VENDOR=YourVendorName&PARTNER=YourPartnerName&PWD=YourPassword&TRXTYPE=S&TENDER=C&ACCT=5105105105105100&EXPDATE=1209&AMT=1.23&ZIP=12345&comment1=Test JNI Transactions" 30

   Don’t forget to insert the correct user/vendor/partner/password.

   Oh, and when I tried it with an account that didn’t have a username (which is possible in payflow pro), it wouldn’t accept the transaction until I set the USER to be the same as the VENDOR.

7. I ran into another problem, which was that I kept getting a NoClassDefFoundError even after following the above steps. I fixed this by adding the absolute path to Verisign.jar to my CLASSPATH:

   $ CLASSPATH=${CLASSPATH:-}:/path/to/directory/Verisign.jar:.;export CLASSPATH

8. As I mentioned, I had a lot of trouble getting the CLASPATH to stick. I couldn’t even run the binary from another directory – even if I speicified the full path to it. In the end, the following sequence was the most reliable means of running a successful transaction:

   $ cd /path/to/binary/

   $ CLASSPATH=${CLASSPATH:-}:Verisign.jar:/path/to/directory/Verisign.jar:.;export CLASSPATH

   $ java PFProJava test-payflow.verisign.com 443 "USER=YourUserName&VENDOR=YourVendorName&PARTNER=YourPartnerName&PWD=YourPassword&TRXTYPE=S&TENDER=C&ACCT=5105105105105100&EXPDATE=1209&AMT=1.23&ZIP=12345&comment1=Test JNI Transactions" 30

   Again, I’d gladly welcome suggestions as to how to make this work more fluidly.

That’s that. You’ve got it installed. The following code will suffice to call it from PHP:

$pfpro_path = '/path/to/directory';

$pfpro_server = 'test-payflow.verisign.com'; // for test transactions. Change this for live transactions.

$vars = '?your=values&to=submit&to=verisign'; // build this string appropriately from your variables according to the payflow documentation, and don't forget to run escapeshellcmd() on each one, since we'll be passing this to exec().

$cmd = 'cd "' . $pfpro_path . '; "; CLASSPATH=${CLASSPATH:-}:"' . $pfpro_path . '}Verisign.jar":.; export CLASSPATH; cd "' . $pfpro_path . '"; java PFProJava ' . $pfpro_server . ' 443 "' . $vars . '"'

$result_code = exec($cmd, $result_string);

Phew!

Good luck…. and if you happen to figure out that whole path issue, drop me a line!

1. Do Not put your repository under your Apache web root, or any virtual host web root. Just don’t. It won’t work.
2. Apache needs read and write permissions on your Subversion directory. The simplest but perhaps not the most secure way to do this is, after you create the repository, to change the owner of the repository directory and all its contents to the user that Apache runs as (in my case, www).

   If you want to still be able to write directly to it (for instance, to set up the configuration) without sudo-ing, you can change the group permissions to allow a group that you’re a member of to write to it. (Like I said, this is probably not the most secure way to do things, but it’s the easiest, and probably fine for something that’s carefully limited to your own machine. I hate dealing with file permissions, so I set it up the lazy way.)

   You can do all of this with OS X’s “Get Info”, or on the command line with chown -R and chgrp -R

3. In your repository, find conf/svnserve.conf, and uncomment the following lines:

   anon-access = read
auth-access = write
password-db = passwd

4. Now open conf/passwd and add a line to the bottom with the format:

   username = password

   subtituting, of course, the username and password that you want to use to access your repository. You can add additional lines for additional users.

5. The SVNbook recommends creating trunk, branches, and tags subdirectories for each project in your repository, although this is by no means required. I don’t ancipate doing a huge amount of branching, but I figured it couldn’t hurt.

   The easiest way to get this set up, if you have already started your project somewhere and can’t change its location without breaking things because of absolute path configurations, is as follows:

   1. Create a tmp directory on your desktop.
   2. Inside tmp, create a directory with the name of your project. You’ll be happiest if this is short and doesn’t include any spaces.
   3. Inside the project directory, create trunk, branches, and tags directories.
   4. svn import . --username YOURUSERNAME --password YOURPASSWORD http://localhost:81/svn -m "repository layout for PROJECTNAME", substituting the appropriate username, password, and projectname. If you’re using a different URL for your repository, substitute that too, of course.
6. You may want Subversion to ignore particular types of files. For instance, with Django, I’m working with Python, which creates a compiled bytecode file for each script, with the extension .pyc. These don’t need to be versioned because each one is recreated automatically from the script every time you change it and run it.

   Different languages and project types will have different files to ignore. There are also OS metadata files like OS X’s .DS_Store and Windows’ Thumbs.db that you probably don’t want to carry around either.

   This is set up on the client side, and you’ll probably want to take care of it before importing or adding anything beyond that skeletal directory structure.

   Open ~/.subversion/config, and locate the [miscellany] section. In there is a line, possibly commented out, that looks something like this:

   # global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store

   Uncomment the line if it’s commented out, and add .DS_Store (if it’s not already there) and *.pyc to the end, so it looks something like this:

   global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store *.pyc

   While you’ve got the file open, you might want to scroll up to the [helpers] section, and uncomment the editor-cmd line, and set it to use your editor of choice.

7. OK, we need to import our project now.

   First, cd into the parent directory of your project directory, and check out the trunk of the project (since the trunk is empty, this will do nothing except create a .svn directory in the project directory, so subversion can handle it properly as a “working copy.):

   svn checkout http://localhost:81/svn/PROJECTNAME/trunk PROJECTDIR

   Then, cd into the project directory and tell Subversion to add everything from your project to the repository. For each subdirectory of the project that you want under version control (Subversion will recursively add directory contents):

   svn add SUBDIRNAME

   Then add the files that live in the root in the project directory that you want versioned. I had a couple files I wanted to ignore (such as my sqlite database), so I just added the Python scripts:

   svn add *.pyc

   Then commit everything:

   svn commit -m "Adding initial project files"

   And you’re done!

But besides that, CVS is really obsolete at this point, and Subversion has really taken over its status as the de facto standard for free, open-source revision control software.

Installation was yet another project that turned out to be super-easy with a little help from Darwinports.

Here’s the full set of steps to install:

1. Grab Apache 2 off Darwinports and get it running separately from the default OS X Apache 1.3 installation (PHP, MySQL, et al entirely optional). Darwinports’ Apache automatically includes mod_dav, which you’ll need.

2. Install Subversion and Apache’s dav_svn_module:

   sudo port install subversion +mod_dav_svn

   Darwinports’ Subversion conveniently includes both server and client. Spiffy.

3. Decide where your repository is going to live. I set up a directory under my user directory, with the full path /Users/myusername/svn

4. Configure Apache to work with Subversion. First, add the following to the bottom of the list of LoadModule directives in httpd.conf:

   LoadModule dav_svn_module modules/mod_dav_svn.so

   Then add the following to the end of httpd.conf:

   <Location /svn ># I think you can change "/svn" to whatever you want the path to be on your server.
DAV svn
SVNPath /Users/myusername/svn/ # Change this to the path you chose in Step 3, of course
</Location>

   If you want to keep your repository private — i.e. only accessible from the machine it’s hosted on, you can add a few lines, like so:

   <Location /svn ># I think you can change "/svn" to whatever you want the path to be on your server.
DAV svn
SVNPath /Users/myusername/svn/ # Change this to the path you chose in Step 3, of course

   Order Deny,Allow
Deny from all
Allow from 127.0.0.1
</Location>

5. Create your repository:

   svnadmin create --fs-type fsfs /Users/myusername/svn

6. Restart Apache

Whee, that was easy.

Browse to http://localhost:81/svn (substitute the appropriate port, of course, if you configured Apache differently) — and if you get something that looks like a really simple webpage, you’re set.

I’m kind of in love with Darwinports right now, in case you haven’t noticed. Next challenge: actually configuring a Subversion repository. I’m seriously crossing my fingers that this is easier than CVS.

Since word on the mailing list is that development versions are not only quite stable, but actually recommended over the stable version, and since I don’t have any deployed apps to worry about breaking, I thought it would be better to upgrade now than later.

Even better, this will make future upgrades as simple as a single subversion command (and, well, some fixes for incompatibilities, but that would be the case anyway, and probably worse if I weren’t to keep up).

I was a bit scared about the upgrade, but it turned out to be much much simpler than I anticipated.  I found a thread on the mailing list about doing just such an upgrade.  It wasn’t very explicit, but when I extrapolated from it, it worked.
Here’s what I did:

1. located my main django directory (had to search for it – it was inside an egg in site-packages), and renamed to django.bak (instead of deleting… in case of emergency).

   If you installed using DarwinPorts, like I did, the location is probably something like:

   /opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/Django-0.95-py2.4.egg/django

2. created a directory for the new installation (anywhere your user has read, write, and execute permissions will do, it seems), and cd-ed into that directory
3. ran

   svn co http://code.djangoproject.com/svn/django/trunk/ django_src

   and

   ln -s `pwd`/django_src/django /PATH/TO/SITE-PACKAGES/django

   (substituting the correct path, of course — in my case, /opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages)

4. Chose a good place on my $PATH to symlink to django-admin.py, and ran

   sudo ln -s ./django_src/django/bin/django-admin.py /DIR/ON/PATH/

   (I dropped it in /opt/local/sbin, since DarwinPorts had added that to my path, and I preferred adding something there to putting it on a main system path.)

And… everything’s up and running, at least in terms of the development server (I hadn’t set it up to run on Apache in the first place — I don’t know if that would complicate things).

Simple, huh?

You see, for the past couple of years, I’ve been a bit frustrated because OS X does not come with a whole lot of Perl modules pre-installed, and for all I googled, I couldn’t find an “idiot’s” guide for moderately-savvy-but-not-expert users like myself to install modules and dependencies on demand.

The only instructions I could find point to Fink, which basically installs modules in a path that isn’t included in the Perl @INC variable (which I still haven’t figured out how to update), meaning you have to manually specify the full path to the modules in every script — which is not a lot of fun if you’re developing on OS X and deploying on Red Hat, for instance.

Moreover, Fink doesn’t seem to make every module available, and it’s not very easy to determine which Fink package you need to install if you need a particular module.

So, with a script that called on several apparently unavailable modules, and a deadline looming, I finally decided to suck it up and figure out how to use CPAN to install them:

1) Make sure you have the Apple Developer Tools installed.

These are on one of your install discs, or available as a huge but free download from the Apple Developer Connection [free registration required]. I thought I had them, but apparently when we upgraded that computer to Tiger, they went missing.

If you don’t have this stuff installed, your installation will fail with errors about unavailable commands.

2) Configure CPAN.

$ sudo perl -MCPAN -e shell

perl> o conf init

This will prompt you for some settings. You can accept the defaults for almost everything (just hit “return”). The two things you must fill in are the path to make (which should be /usr/bin/make) and your choice of CPAN mirrors (which you actually choose don’t really matter, but it won’t let you finish until you select at least one). If you use a proxy or a very restrictive firewall, you may have to configure those settings as well.

If you skip Step 2, you may get errors about make being unavailable.

3) Upgrade CPAN

$ sudo perl -MCPAN -e 'install Bundle::CPAN'

Don’t forget the sudo, or it’ll fail with permissions errors, probably when doing something relatively unimportant like installing man files.

This will spend a long time downloading, testing, and compiling various files and dependencies. Bear with it. It will prompt you a few times about dependencies. You probably want to enter “yes”. I agreed to everything it asked me, and everything turned out fine. YMMV of course. If everything installs properly, it’ll give you an “OK” at the end.

4) Install your modules. For each module….

$ sudo perl -MCPAN -e 'install Bundle::Name'

or

$ sudo perl -MCPAN -e 'install Module::Name'

This will install the module and its dependencies. Nice, eh? Again, don’t forget the sudo.

The first time you run this after upgrading CPAN, it may prompt you to configure again (see Step 2). If you accept its offer to try to configure itself automatically, it may just run through everything without a problem.

There are a couple of potential pitfalls with specific modules (such as the LWP::UserAgent / HEAD issue), but most have workarounds, and I haven’t run into anything that wasn’t easily recoverable.

And that’s it!

Did you find this useful? Is there anything I missed?

I decided a couple weeks ago that I wanted to learn Django as well as Ruby on Rails. Django is a little bit less trendy, but seems to have more flexibility, and gives you an entire admin section of your app “for free”, as opposed to RoR, for which there are a zillion different ways to hack on user management, and no sense of “best practices” for a novice.

Django requires an up-to-date installation of Python, and a number of other dependencies, including a database API for Python. The best installation instructions I could find for OS X (one of the reasons I use a Mac is the availability of all these great UNIX tools that are so useful for a webmaster) recommended using DarwinPorts (soon becoming MacPorts) to simplify installation.

DarwinPorts is awesome.

Getting the Latest Apache / PHP / MySQL

I peeked through the list of available packages, and decided that as long as I was at it, I might as well add an Apache 2 / PHP 5 / MySQL 4.1 server to run on port 81 alongside the default Apache 1.3 / PHP 4 / MySQL 4.0 that I already had on port 80.

An earlier attempt to do this had run out of steam as I realized I would have to choose, locate, configure, and compile all my Apache modules by hand, which is really beyond my ability and ambition. But DarwinPorts would allow me to install Apache with a whole bunch of common modules included, and would download and install all the dependencies for each one automatically.

Well, even on my top-of-the-line-a-year-ago machine, this stuff takes a while to compile, but about an hour later (after cursing at myself for misunderstanding the sudo -u mysql command as running MySQL and trying to fix an error by prepending a path to the username) I had a working secondary server. DarwinPorts not only installs dependencies for each piece, and not only configures everything for you, and not only reminds you of changes to make to your $PATH variable in case the installer couldn’t, but sometimes it even tells you what commands to run after installing each program to properly do things like initalize databases. Sweet.

Here’s how you do this:

1. port install mysql4 +server
2. port install apache2 +server
3. port install php5 +mysql4 +apache2
4. copy httpd.conf.sample to httpd.conf
5. [optional] change path in DocumentRoot and associated directives
6. [optional] change Listen 80 to Listen 81 (If you want to run side-by-side with an Apache 1.3 installation on port 80)
7. add the following to the directive:
   AddType application/x-httpd-php .php
   AddType application/x-httpd-php-source .phps

Don’t forget to follow the extra directions DarwinPorts gives you.

Python, PostgreSQL, and Psycopg Spell Problems

I easily updated my Python installation, and then I ran into trouble. You see, the instructions I had for DarwinPorts were for installing with SQLite. I wanted to use PostgreSQL, partly because I figured it would be a useful thing to learn, and partly because skimming the initial tutorial and its comments had showed me that PostgreSQL was perhaps the optimal database choice because of its handling of foreign key constraints.

The main installation instructions for OS X used PostgreSQL, but compiled it by hand.

So I decided to wing it. The DarwinPorts available ports list included three versions of the PostgreSQL package, so I picked the latest one (postgresql81), and installed it. Then I installed the next dependency (py-egenix-mx-base). No problem. And then I ran into the final piece, psycopg.

Psycopg is a package that allows Python to interact with PostgreSQL databases. The instructions were very specific about installing version 1.1, not version 1.0 or 2.0, of psycopg. Great. I asked DarwinPorts to install psycopg.

Well, first problem: the DarwinPorts psycopg package depends on the postgresql8 package, not postgresql81.

Second problem: every server from which it attempted to download postgresql8 timed out.

I was a little bit flummoxed at this point.

I backtracked, downloaded the source code for psycopg, compiled it by hand using the main OS X installation instructions (I had to tweak a lot of paths to reference DarwinPorts’ installation locations), and boom! I’m off and running.

Phew.

I feel like an idiot for not documenting the exact commands I used, for the edification of future generations. If I ever do this again and am not running down blind alleys looking for solutions to problems caused by my own typos, I promise to do so faithfully. In the meantime, here are the steps to do it the easy way (assuming the postgresql8 servers are working):

1. sudo port install python24
2. sudo port install postgresql8
3. sudo port install py-egenix-mx-base
4. sudo port install py-psycopg
5. [optional] sudo port install subversion (If you’re using the development version of Django, or just want subversion)
6. Install Django

Next up, I’ll tell you what it’s like to jump from MySQL to PostgreSQL, and all about my experiences with the Django tutorial.