Well, it took some struggle, but I got the Python project up and running on the Mac. Many of my struggles had to do with working in an unfamilar environment, although now I'm catching myself typing ls in DOS command shells :). A few of my struggles were just the rtfm kind, where I couldn't understand why it wouldn't work after I did step one and three... until the obvious answer, step two, hit me on the eighth or tenth read. doh.
One of the key ideas was to understand that you might install a couple of different "pythons" in a couple of different directory structures, but you only needed to specify the path to the one you wanted to work with, and they could each be used autonomously. Easy to say now, hard to grok when I was in the trenches. So, fink's python is installed in /sw and works fine with other fink projects, MacPython is installed in /usr/bin and appears in the Application folder. Launch the first with "python" and the latter with "pythonw" or specify paths for it to be explicit.
8:52:34 PM comment []
Interesting story here of a fellow switching out his laptop for a Mac Powerbook, and how he was able to continue to function in a nearly pure Windows environment with the Mac's software compatibility and just a few third-party tools. The benefits of having a Mac helped, too! [OSNews]
8:42:38 PM comment []
I'm been talking with a couple developers who are working on a project in Python and they offered to give me access to the source code. I was interested in trying it out on the Mac. In order to do that, I needed the SubVersion client. I visit http://subversion.tigris.com, and there are instructions for downloading it, using a tool called fink. It turns out that fink is a friendly front end for the apt-get and dpkg tools of Debian, modified for OS X usage. Lots of packages available, but first I have to download and install fink. Fink has an optional GUI, Fink Commander, and I throw that in the mix, too. After install, of course, fink needs to be updated to the latest versions. Doing that fails, as Fink is depending on certain Apple developer tools being available. Surfing the Apple site for a while tells me the developer tools are right here on my hard drive, under "Installers." I install the Apple developer tools. Fink updates. I try to install the SubVersion package, and it fails with an error about a java14-dev package it can't find. After trying a few variations on the command, I hit Google and find a link that tells me I need the Java 1.4.2 SDK update of the Apple Developer Tools from the Apple site.
Going to the Apple site reveals that you have to register at the Apple Developer Connection. I register. Plodding through the interface, I attempt to download the Java SDK. It fails. Three times. I log out, and back in to the ADC. I download and install the Java SDK successfully. I try to install the SubVersion package again. Finding all these delightful tools on my machine, it attempts to recompile everything it can find, text scrolling by for an hour before it reports an error. It seems that the X11 server I have has a conflict with the XFree86 server it wants to install, and it tells me there is a way to resolve this, but I can't understand the instructions. A little more surfing and I find the page on the fink site (http://fink.sourceforge.net/doc/x11/inst-xfree86.php) that explains the difference between Apples X11 and XFree86, again, with instructions I can't understand. I read it, three times. I could just uninstall the Apple X11 server, but I installed that in order to run OpenOffice.org, and Apple's X11 was the recommended choice. I walk the dogs. I break for dinner.
I read it again. I decide it wants me to install the X11 SDK that comes with the Apple X11 package. Can't find it on a search of the Apple site, but digging around on the hard disk in the Installers folder finds it and it installs. Update fink, per the instructions, and then try to rebuild "fink install system-xfree86" with no luck: "no packages to install." Return to the shell for installing svn and try that process again. It asks me to pick the correct 'virtual packages' for python and apache I go with the defaults. It informs me it needs to install 34 dependent packages (down from 52 the first run, iirc) including such things as ruby, guile, Python and Apache, and I tell it to continue. Mindless text scrolls across the terminal as make and compilers and sh and rm fight for notice. Staring at the screen just lets me catch glances at warnings about missing prototypes and implicit declarations; nothing I feel I have a lot of control over.
I fall asleep at the machine at 9:30. The dog scratch at the door at 5:10; time to get up. Compile completed successfully. I download the packages from Subversion without a problem.
No wonder Open Source development takes so long.
9:01:59 AM comment []
