My goal is to have shortcuts in one place, organized by project, as the ultimate launcher.

Here were some good initial attempts:

• Firefox bookmarks might be a nice way to go, but doesn’t make it easy to link to local files, so that solution was quickly dismissed.
• Butler did this well — a quick click in the menu bar pulls up a hierarchical list of projects and shortcuts to resources for each project.  You could easily drag and drop URLs as well as local file shortcuts to Butler as well.  This approach basically created a nice external bookmark manager not tied to any one browser and able to link to files of all types.
• Recently I noticed that Snow Leopard’s improved Grid (in the Dock) now allows for navigating down a hierarchy of folders quickly, so though about putting my shortcuts there.  The only problem is that the dock is “way down there” (irregardless of where you put the dock) and takes time to mouse around.

Each tool took their own approach, and I had to pick one since I couldn’t easily use multiple ones. Also, graphical solutions still take precious time to drag your mouse and navigate through the hierarchy.

Then a better idea.

Spotlight is quick and fast for searching so is ideal (just press apple-spacebar) though typing in search phrases still brings up lots of extra information I don’t want.

So how do I universally “tag” resources and bring them up quickly?

First, the cool 2006 (and still usable) metadata solution mentioned on LifeHacker: Apple-I on files you want to tag, then add a custom tag into the comment box. Prefix with & so it’s quick to find without bringing up a lot of other crap.  For my common Web Collective company shortcuts, I used &wc.  Now, when I jump to Spotlight and type &wc, I instantly see all my shortcuts.

This was great, but then I found tagging nirvana on OSX.

An ecosystem of tagging tools has popped up around a free and open source OpenMeta Tag standard.

OpenMeta means that you can now tag files, folders, emails, web pages, etc, with an assortment of tools, and then search for them with an assortment of tools. No need for custom tagging in the file “comment” field, and no need to use a proprietary tagging system that locks you into one tool. (Btw, for web pages, I drag a shortcut from the browser to my file system, then tag the resulting .webloc file)

The simplest workflow consists of tagging files by dragging/dropping them onto Tagger, then pulling them up quickly in Spotlight.  To pull up all my shortcuts tagged with “wc” you just type “tag:wc”.  This is a free solution and works well.

Next in the evolution are tools such as Tags or Punakea or Leap — which make it easy to tag, while also having nice integrated search features. Tags makes it easy to tag email (in addition to files and folders), Leap (the creator of OpenMeta) is interesting because it has a very fast and flexible searching mechanism and basically does all the work of the Finder with the powerful addition of tagging and rating.  These are all paid applications — well worth it if they help you to better organize.

I’m still playing around to find the right combination of tools for my own workflow.  See http://code.google.com/p/openmeta/wiki/OpenMetaApplications for a nice list.

Tagger and Spotlight are working well for quick shortcuts — Tags, Punakea and Leap start to show what a world would be like when relying less on hierarchy and more on tags.

Hmmm, TagFolders looks pretty interesting too…

NOTE: This post is for installing Python 2.4 on a brand new Snow Leopard Instance. If upgrading on top of Leopard, you may have to update easy_install, macports, etc.  More Googling around may be required.

Though I had to create two buildouts to get this to work — is there a way to get this into one buildout?

I first tried to create one buildout by combining  Florian Schulze’s buildout recipe with a standard Zope recipe — but since initial bootstrap was run by Python 2.5, I couldn’t get the Zope instance to use the new Python 2.4. So I first ran a buildout to build Python 2.4 (using OSX-installed Python 2.5), then used that new Python 2.4 to run bootstrap.py on the Zope 2.8.x buildout.

Here’s the recipe I used to just build Python 2.4 (requires Florian’s buildout, see Alexander Limi’s comment below for where to find this):

[buildout]
#extends = src/snowleopard.cfg     # no longer required as Joe mentions below
python-buildout-root = ${buildout:directory}/src
parts -=
   ${buildout:python25-parts}
   ${buildout:python26-parts}

[install-links]
prefix = /opt/local

Then I ran a simple Zope 2.8 buildout to see if it would compile (using new Python 2.4 to bootstrap), and it did!

[buildout]
parts =
   zope2
   instance

[zope2]
recipe = plone.recipe.zope2install
url = http://www.zope.org/Products/Zope/2.8.9.1/Zope-2.8.9.1-final.tgz

[instance]
recipe = plone.recipe.zope2instance
zope2-location = ${zope2:location}
user = admin:admin
http-address = 8080
debug-mode = on
verbose-security = on

Here is my initial post:

I have to say — most everything I’ve installed on a fresh Snow Leopard install has worked flawlessly and swiftly — except for (the minor inconvenience of) iStat not working.  UPDATE: iStat 2.0 is available for Snow Leopard now. There’s a new beta of MenuMeters too for Snow Leopard.

There are also nice subtle improvements, see Mac Life’s 100 Top Snow Leopard Tips, Trick and Features for improvements to Preview, Expose, Stacks, etc.  I’ve very happy with the upgrade.

Now for the bad news for those like myself who depend on Python 2.4 for Plone, since many versions of Zope require Python 2.4.  I also use Python for Django, though that should run fine on Python that shipped with Snow Leopard.

You can read many of the initial details around the web, but here’s what I’ve experienced and have been able to put together:

• Note that these details are for a fresh Snow Leopard install – there are a different set of issues if you’re upgrading over your existing Leopard.  NEW: “Clark’s Tech Blog” has a nice write-up about upgrading Python after upgrading Leopard to Snow Leopard.
• Snow Leopard ships with Python 2.5.4, and this runs as a 32-bit application.
• I also need 2.4 branches of Python too, so I tried rolling my own (as usual) and it didn’t compile.  I then followed that thread for awhile.
• I then thought I pulled a fast one when I compiled from MacPorts and everything ran great!
• … but then I compiled Zope, and attempted to run an instance.  I saw a mysterious “No such file or directory” error.  Hmmm, I can navigate to that file, but running the script with my new Python interpretor was causing this error.
• After digging around with Activity Monitor, I discovered that the Python I built from scratch was running as a 64-bit app — while the Python that comes with Snow Leopard was only running 32-bit — which is telling, since most everything else on Snow Leopard is running 64-bit.
• Guessing that the the mysterious “No such file or directory” (when the file and directory did indeed exist) was due to a weird cocktail of 32-bit pieces living with 64-bit pieces.
• My latest theory was that I needed to figure out how to build Python as 32-bit.  I played with Macports and various architecture settings to hardwire this, but long-story-short — the architecture override isn’t used everywhere — so parts still compile natively as 64-bit on Snow Leopard.
• The best thread on the topic (that’s steadily growing) is here: http://bugs.python.org/issue6802 with msg92153 left today, which basically offers some additional settings for compiling Python as a 32-bit app (for Python 2.6).  Also mentions that Snow Leopard did some magic to get Python 2.5 working as a 32-bit app.
  
• My hope is that once “32-bit” Python 2.4 happens, the rest of the Zope install, etc, will be back to the good ol’ days in Leopard.

Plan B’s:

Otherwise, to save some headache, I’m wondering about installing a small Linux distro on VMWare as a local mini web-server where I can easily install Python and Zope — though that’s a bit of a pain too.

Luckily I also have my old Leopard in a separate partition (see my Extra life for my MacBook Pro with Snow Leopard and inexpensive hardware blog entry) and can boot that if necessary to work on various Zope/Plone sites (that required Python 2.4) while this is all being sorted out.

Now time to see if I can get 32-bit Python 2.4.6 compiled and installed, while waiting for more patches and information to appear…

My goals:

• Max out memory to 3GB (up from 2 GB) — $29
• Upgrade hard-drive to 500GB (up from 120GB) – $129 for a 2.5″ Seagate Momentus SATA 7200 RPM.  My current drive is 5400 RPM, so this will be a speed improvement too.
• I also want to install the OS from scratch as a chance to clean things out.
• Hey, I can then even upgrade my wife’s laptop with my 120GB drive!

The steps have been pretty easy:

• Backup whole drive using SuperDuper! to a bootable external drive.  If I didn’t want to install Snow Leopard from scratch, you could then just transfer your previous OS back to the new hard-drive and be done.
• Upgrade memory, piece of cake
• Upgrade hard-drive. I like to do this sort of thing myself, albeit Apple is the official place to have this done.  This takes a Torx 6 screwdriver, and some patience, but was fairly easy to do thanks to http://www.ifixit.com
• Start Installing Leopard.  Note that you do not need to install Leopard first for a brand new install.  I just put in Snow Leopard, and booted holding down “C” and the installer popped up.
• Since the drive is large, I decided to take an extra step of partitioning my drive into 2.  You can run Disk Utility right before starting the install to create these.  One partition as my main one for Snow Leopard, and the other as a complete bootable Leopard exactly the way my laptop was before the upgrade — just in case I forgot something — and I can easily pull files over while doing the big reinstall-everything-from-scratch step.  SuperDuper! makes this easy — both to backup your drive, and restore it on a new partition.
• Frolic in all my new hard-drive space and anticipated speed improvements — more memory, faster hard-drive and faster OS.