If you’re using Apple Keynote, you may have noticed that there isn’t an easy way to extract the presenter notes attached to your slides (of course you could do it manually, one slide at a time, but that’s pretty tedious!).

The following AppleScript code allows you to automate this action by pulling out all presenter notes from an open presentation and save them to a Markdown file.

Inspired by:

More on AppleScript:

Tip: make the script executable and add an alias for it in order to be able to call it from the command line easily.

The basic idea: keep all of your pdf files in the cloud using a Dropbox folder; also, keep the Mendeley database and preferences in the cloud, so that they are shared across computers. Finally, point Mendeley to that Dropbox folder and let it do the rest for us (e.g. keeping it organised etc.).

Warning: since with this method the preferences and database are shared across computers, you must make sure you don’t use Mendeley at the same time on both computers as that could lead to some conflict!

This recipe assumes that you have two macs and both Dropbox and Mendeley installed on both of them. We’ll call one of the two machines mac-1, and the other one mac-2.
Also, the method requires that you are using the same username on both macs. I know, this is a big limitation, but since Mendeley indexes pdf files using their full path that’s the only way for things to be wired up correctly (otherwise on one of the two macs the path of the pdf files will be broken).

1. Set up Mendeley and DropBox on mac-1

On Mac-1, create a Mendeley folder in your Dropbox. Within that, create two new folders, pdf and db.
Now launch Mendeley Desktop and in the preferences panel set the pdf-files location to the pdf folder you just created. After clicking on ‘apply’ Mendeley will move your existing library (if you have one) into the new folder. Wait till that’s finished before moving on to step 2.

2. Add Mendeley database to DropBox on mac-1

Close Mendeley Desktop on mac-1. Now open up the terminal and symlink the ~/Library/Application Support/Mendeley Desktop folder to the db folder just created in Dropbox. This way the DB and preferences can be shared across computers.

[mac]@mac1:~/Library/Application Support>cp -r Mendeley\ Desktop/ ~/Dropbox/Mendeley/db/
[mac]@mac1:~/Library/Application Support>mv Mendeley\ Desktop/ _backup_Mendeley_Desktop/
[mac]@mac1:~/Library/Application Support>ln -s ~/Dropbox/Mendeley/db/Mendeley\ Desktop .

Dropbox will start cloud-syncing the new folder we added. In the meantime, you can try launching Mendeley and checking that everything works at it should.

3. Set things up on mac-2

Put to sleep mac-1 and wake up mac-2. If you’re online, Dropbox on mac-2 will immediately start downloading all the new stuff you previously added to it (via mac-1). In the meantime, quickly open up Mendely and update the preferences as we did in step 1 above. Then closed it down.

Once the Dropbox download is finished, we can set up the symlink to the Mendeley database as we did in step 2 (no need to copy the db folder this time, because we’re using the folder already present in Dropbox/Mendeley/db):

[mac]@mac2:~/Library/Application Support>mv Mendeley\ Desktop/ _backup_Mendeley_Desktop/
[mac]@mac2:~/Library/Application Support>ln -s ~/Dropbox/Mendeley/db/Mendeley\ Desktop .

That’s it. You now should be able to open up Mendeley and have your entire library synchronised across the two computers (effectively, you’re working on a single library since your database is shared too).

Obviously you can still use the web-sync service, which is handy for example if you use also some mobile device. There you’ll still have the 1gig limitation for the pdf files, but at least for me that’s hardly a problem cause I don’t need to have my entire library on the go all the time (I just have a folder called ‘syncedStuff’ in Mendeley Desktop and synchronise only the files attached to that).

If things go wrong..

Well, I’d expect any wise pdf-collectors to make regular backups of their precious databases. In some cases though it’s not just a matter of putting things back as they were; for example once I moved the pdf source files to a different location, launched Mendeley and discovered that although my library was still there all the pdf links were broken.
Since I wanted to keep the new paths for all the pdf files, as a last resort I tried to hack into Mendeley’s own SQLite database and clean things up myself.

Here’s another post that explains how to modify Mendeley’s database manually: Using Mendeley effectively on multiple systems using an external storage drive

This is pretty easy actually. Mendeley stores the full file paths to your files in its database. In particular, the database file can be found in /Application Support/Mendeley Desktop, and it is named like this: youremail@www.mendeley.com.sqlite.

All you have to do is this: close down Mendeley (if it’s running), make a backup copy of the database file for safety purposes, then open it up using a SQLite GUI (e.g. on mac you can use SQLite Browser which is free). You’ll see that the Files table contains all the (wrong) paths to your pdf files; now you can update these paths by launching a simple ‘execute’ command, e.g.:

update Files set 
  localurl = replace(localurl, '/Users/me/Dropbox/Mendeley/old/path/', '/Users/me/Dropbox/Mendeley/new/path/');

Make sure the command did its job by checking the Files table contents; if that’s the case, the next time you launch Mendeley it won’t have no broken links anymore!

I emailed the customer service people at Flickr, they promptly replied that it wasn’t their fault but most likely a bug with other apps I had previously authorised to edit my Flickr collection (e.g. iPhoto or Aperture). Bad news: apparently whatever happened now what’s lost is lost forever. Not much to my consolation, the same happened to other people, for example check this post or this post to see alternative versions of the problem from 2010 and 2007.

So I’ve suddenly realised the cloud isn’t that secure a place, as yet. It’s time to change strategy: use flickr for sharing and my local HD for backup!

The good news is that if you know a little programming you can download your entire Flickr collection without having to pay a cent, for example by using Python. There are a few free libraries out there for accessing the Flickr APIs, such as flickrpy and FlickrAPI. They both require you to fiddle a little with the code (at the very least, get a personalised passkey from Flickr and add it to the python program) in order to get what you want.

The one I’ve gone for instead is a little package called flickrtouchr, which is even easier to use. After downloading you just have to run it from the command line and it’ll begin browsing your whole Flickr collection and download pictures at the highest resolution available. I have more than 8000 photos, and it worked like a charm – beware though – it took more than 10 hours on my TalkTalk connection.

Thanks Dan@hivelogic.com for writing this code – couldn’t be asking for more!

[mac]@mike:~/Dropbox/code/python/_libs/dan-hivelogic-flickrtouchr-9ba645b>python flickrtouchr.py ~/Desktop/FlickrBackupFolder

In order to allow FlickrTouchr to read your photos and favourites
you need to allow the application. Please press return when you've
granted access at the following url (which should have opened
automatically).

http://api.flickr.com/services/auth/?api_key=e2245325378b5675b4af4e8cdb0564716fa9bd&perms=read&frob=8856734hhgbbhsksd19443-caa77e89367asbbhfa2ba-600258&api_sig=a4aasdbbnb345c7fb46bdd33cfa65ec17bb32a

Waiting for you to press return

Egypt 1 ... in set ... Sharm el Sheik, Dec 2011
Egypt 2 ... in set ... Sharm el Sheik, Dec 2011
Egypt 3 ... in set ... Sharm el Sheik, Dec 2011
Egypt 4 ... in set ... Sharm el Sheik, Dec 2011

..... etc….

That’s the gist of it. I finally took a look at django.contrib.staticfiles last week, so here’s a brief report on how to get it to work (p.s. a couple of related threads on stack overflow can be found here and here).

1. Set up the static and media paths settings

My previous settings looked like this:

# the site root is one level up from where settings.py is
SITE_ROOT = os.path.dirname(os.path.realpath(__file__)).rsplit('/', 1)[0]
MEDIA_ROOT = os.path.join(SITE_ROOT, 'static')
MEDIA_URL = '/static/'
ADMIN_MEDIA_PREFIX = '/static/adminmedia1.3/'

The media root contained all of my static files, some of which I had to copy in there manually, each time I added a new django app to my project. On the production server, the MEDIA_URL is mapped to a local path (in the apache conf settings) that is essentially a duplicate of the /static directory we have in the development server. The only difference, the static stuff is delivered directly by Apache, bypassing django (=so to make it faster).

The new way of declaring these variables is this instead:

MEDIA_URL = '/media/uploads/'
STATIC_URL = '/media/static/'
ADMIN_MEDIA_PREFIX = '/media/static/admin/'

# Absolute path to the directory that holds media uploaded
# I keep the uploads folder at the project-root level server
MEDIA_ROOT = os.path.join(SITE_ROOT, 'uploads') 

# physical location of extra static files in development server
STATICFILES_DIRS = (
    os.path.join(SITE_ROOT, 'myproject/static'),
)
# path used with "python manage.py collectstatic"
# I normally put this at the project-root level that contains also the wsgi files for apache
STATIC_ROOT = os.path.join(SITE_ROOT, 'apache/static')

Obviously on a production server, you will have to set up the required aliases in the apache conf file, so that MEDIA_URL and STATIC_URL are pointing at the right physical locations:

Alias /media/uploads/ /path/to/mysite.com/uploads/
Alias /media/static/ /path/to/mysite.com/apache/static/

The django docs explain the new approach with these words:

In previous versions of Django, it was common to place static assets in MEDIA_ROOT along with user-uploaded files, and serve them both at MEDIA_URL. Part of the purpose of introducing the staticfiles app is to make it easier to keep static files separate from user-uploaded files.

For this reason, you need to make your MEDIA_ROOT and MEDIA_URL different from your STATIC_ROOT and STATIC_URL.

The STATIC_ROOT directory is not necessary in the development server: in fact is only used if you call the collectstatic manangement command. It’s not needed to add the directory to the STATICFILES_DIRS setting to serve your static files!

Furthemore, the STATICFILES_DIRS variable tells Django of the location of static files which are not within specific applications. Mind that during the ‘collection’ operations also these files will be copied into the STATIC_ROOT directory.

2. Add context processors and the app

Add the required context processor in setting.py:

TEMPLATE_CONTEXT_PROCESSORS += 'django.core.context_processors.static'

Add also the new static app to your installed apps:

INSTALLED_APPS = (
....    
    'django.contrib.staticfiles',    
.....
)

Keep in mind that it’s very likely that in your templates you will have to manually change all references to MEDIA_URL into STATIC_URL!

3. Url configuration

On your development server, this is what you would do:

from django.contrib.staticfiles.urls import staticfiles_urlpatterns
# ... the rest of your URLconf goes here ...
urlpatterns += staticfiles_urlpatterns()

This will inspect your STATIC_URL setting and wire up the view to serve static files accordingly. Don’t forget to set the STATICFILES_DIRS setting appropriately to let django.contrib.staticfiles know where to look for files additionally to files in app directories.

WARNING: the staticfiles_urlpatterns helper function will only work if DEBUG is True and your STATIC_URL setting is neither empty nor a full URL such as http://static.example.com/ (more info here).

Finally, mind that in this new approach you will need to arrange for serving of files in MEDIA_ROOT yourself; staticfiles does not deal with user-uploaded files at all. You can, however, use django.views.static.serve() view for serving MEDIA_ROOT in development (for more info see Serving other directories).

if settings.LOCAL_SERVER:     # ===> static files on local machine    
    urlpatterns += patterns('', 
        (r'^media/uploads/(?P<path>.*)$', 'django.views.static.serve', 
            {'document_root': settings.MEDIA_ROOT, 'show_indexes': True}),
        )

In the end, I conflated the two things into this code (ps I’ve added a variable called LOCAL_SERVER to quickly see which platform I’m on):

if settings.LOCAL_SERVER:     # ===> static files on local machine
    from django.contrib.staticfiles.urls import staticfiles_urlpatterns
    urlpatterns += staticfiles_urlpatterns()    
    urlpatterns += patterns('', 
        (r'^media/uploads/(?P<path>.*)$', 'django.views.static.serve', 
            {'document_root': settings.MEDIA_ROOT, 'show_indexes': True}),
        )

4. On your production server

Easy: in your urlconf there’s no need to do anything, as static urls are usually handled by Apache directly. However for that to happen what you have to do is collect all static files into the directory that apache is looking into, that is, the one specified with the STATIC_ROOT setting. This is how you do it:

python manage.py collectstatic

This shell command will
a) look in the /static/ directory of each of the apps of yours INSTALLED_APPS setting.
b) look in directories you specify in the STATICFILES_DIRS setting.

…and copy whatever it finds into the STATIC_ROOT directory, as defined in your settings (ps: it’ll preserve the original directory structure).

That’s all folks!

Unfortunately as usual an OS upgrade is never as smooth as I would like it to be; so here’s a list of the problems I ran into (and still am), with pointers to solutions whenever I found one.

Tip: A useful place where to get info about Lion is here: http://osxdaily.com/tag/mac-os-x-10-7/

1. Wi-Fi disconnection issues

This is quite a bad one: my wifi connection wouldn’t stay on for more than 2-3 minutes at times, making it impossible to do any continuative work online. After a lot of swearing and searching online, I found a good solution on this article on iLounge.com. The article offers many solutions, but the one that worked for me is to manually downgrading the Atheros WiFi driver which seems to be ill on Lion to the version provided with Snow Leopard (comment 53). Here’s the recipy:

1. run kextstat | grep -i atheros
if a line was returned, you are most likely using Atheros WiFi card and the related kext
2. In your home folder create two directories: cd && mkdir New Old
3. If you have a copy (time machine backup) or other system installed with Snow Leopard (as latest as possible), take a copy of /System/Library/Extensions/IO80211Family.kext and put it into ~/Old/ directory
[P.S. if you don’t know where to get that file, I’ve uploaded a copy here: IO80211Family.kext.zip]
4. (Back on to your main system) gain root access: sudo -s
5. Move: mv /System/Library/Extensions/IO80211Family.kext ~/New/
6. Move cache file: mv /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache ~/New/
7. copy old kext: cp -r ~/Old/IO80211Family.kext /System/Library/Extensions/
8. go to: cd /System/Library/Caches/com.apple.kext.caches/Startup/
9. rebuild cache: kextcache -v 1 -a i386 -a x86_64 -mkext kernelcache /System/Library/Extensions
10. Using GUI Utilities->Disk Utility->Macintosh HD->Repair permissions
11. pray and reboot

2. Install the latest Xcode and Developer Tools

This is number 2 in the list, but really it should be number 1 if you are a software developer. The latest Xcode (4.2, get it on the apple store for free) includes all sorts of low and high level programming frameworks, from C compilers to Python interpreters. In other words, without reinstalling Xcode tons of software development environments won’t run as usual!

Installing Xcode is very easy, here’s a nice tip to keep in mind though (as found here):

When installing XCode, for some unknown unholy rea­son, if you have not quit itunes, and itunes helper (see activ­ity mon­i­tor) prior to start­ing the XCode installer, the install will hang. Do your­self a favor and kill it with fire.

Also, two more crucial things to keep in mind:

– Remem­ber; the binary direc­tory for the dev tools is in /Developer/usr/bin/ — this includes gcc-4.2
– Do your­self a favor, drop “export ARCHFLAGS=”-arch x86_64″” into your .bash_profile.

The last point is extremely important; make sure you do that otherwise you’ll easily run into all sorts of 32 vs 64 bits architectures conflicts that (if you’re like me) you have no time to get into (more info here).

3. Fix your Python installation

On my iMac I couldn’t run iPython anymore; this was surprisingly easy to fix, I just run again easy_install ipython from the command line and there you go iPython went back up (version 2.7, the default one with Lion).

This didn’t work on my other mac though (a slightly older MacBook); the easy_install ipython trick failed with a DistributionNotFound error; if this is the case, you probably have to re-install Apple’s Developer Tools (see point 2 above).
However before doing that you might want to consider this good tip which I found here:

1. Make a list of all the third-party libraries you currently have installed under Python 2.6, because you’ll have to reinstall all of them for 2.7 and you won’t have the 2.6 site-packages directory to refer to.
2. Update to Lion.
3. Update to Xcode 4.1. It’s free in the App Store.

Good, so I installed XCode 4 (= Apple’s Developer Tools) but I still had a problem: for some reason the default python binary (/usr/bin/python) was still pointing at the 2.5 release, instead of the 2.7 that comes with Lion. This was easily fixed by issuing this command:

defaults write com.apple.versioner.python Version 2.7

Two final steps are then required:

a) Download the 2.7 version of setuptools and install it (e.g. sudo sh setuptools-0.6c11-py2.7.egg);
b) re-install iPython via setuptools: sudo easy_install ipython

Obviously I’ll have to manually install under 2.7 all the libraries I used to have on 2.6, but that can be done incrementally and thanks to easy_install it’s also quite quick.

For more discussions on python and Lion, check out these posts: Quick Python/Developer tips for OSX Lion and Python problems on Lion.

4. The Mercurial binaries disappeared

What the heck. You need to reinstall Mercurial using the package available here: http://mercurial.berkwood.com/ and Python problems on Lion

5. Omnigraffle can’t save files anymore

My 5.0 copy of Omnigraffle loaded and let me create stuff just fine, but it won’t save files anymore. I got an error message that looked like an internal error (“class bla bla can’t be subclassed by bla bla bla”) each time I tried to save my work. Bugger.

Couldn’t find a solution to this; I guess that getting the latest version (5.3 I think) will solve the issue (it’ 70 dollars though).

6. Java runtime missing

Lion does not provide a Java runtime by default, so you need to install it separately. No worries: that’s going to happen automatically as soon as you try to run a Java application; alternatively, you can do that manually here.

7. The Finder Sidebar Icons colours (well lack of..) are depressing

Why on earth haven’t they made that a preference we can change? There’s a way around it though, and it is described here. This is the gist of it:

– Download and install SIMBL, which you can get here
– Download the ColorfulSidebar SIMBL plugin (direct link) or visit the developers home and mount the DMG file
– Move the ColorfulSidebar.bundle into the following SIMBL plugin folder: ~/Library/Application Support/SIMBL/Plugins/
– Either login and logout of Mac OS X, or just kill the Finder through the Terminal to relaunch it: killall Finder

Unfortunately this solution won’t stick after an OS reload; but it’s enough to relaunch the Finder (killall Finder) to reload the plugin.

P.S. If you can’t access the ~/Library folder using Finder, check out point 12 below!

8. Safari Won’t Reopen To HomePage

Apple changed the way new windows open. In Safari, if you set the “New windows open with” preference to “Homepage”, then ALL new windows will now open with your homepage setting, including the initial startup window. In past versions, you could set that preference to “Same Page” while startup would auto open the homepage.

Solution: go to System Preferences/General/ and uncheck the “Restore windows when quitting and re-opening apps” option.

9. The CD-TO utility disappeared

A small utility I’ve been using all the time is cdto, a mini application that opens a Terminal.app window cd’d to the front most finder window.

That doesn’t work anymore, but the good news is that as of Mac OS X Lion 10.7, Terminal includes exactly this functionality as a Service, which you can set by going to System Preferences > Keyboard > Keyboard Shortcuts > Services (check this useful blog post for more details). Also, a more in-depth discussion of the various options available can be found on stackOverflow.

In addition, Lion Terminal will open a new terminal window if you drag a folder (or pathname) onto the Terminal application icon, and you can also drag to the tab bar of an existing window to create a new tab.

Update: CDTO has a Lion version available too. Also, another free software that offers the same functionalities is Go2Shell.

10. Visor doesn’t work anymore

Yes because Visor (a pumped-up version of the terminal application) relied on SIMBL, which is handled different on Lion. Not a problem, just download TotalTerminal, which is an updated and more stable version of Visor.

For original Visor 2.2 users: TotalTerminal plugin is not injected into Terminal.app automatically like with SIMBL. You have to launch TotalTerminal.app to inject the plugin into Terminal.app. You might want to put TotalTerminal.app into Startup Items.

11. VmwareFusion won’t work

VmwareFusion is a Virtual-PC software that people use to run windows on a mac; I was using an older version of it and it looks as if this is incompatible with the 64-bit architecture of the Lion operating system.

Solution: nothing else than getting the latest version of VmwareFusion, which currently sells for 50 dollars. Bugger.

12. Customize the Finder

Get the Library folder to show again: by default, the Library folder in your home directory doesn’t show in Finder. Just type this into your terminal app to fix it:

chflags nohidden ~/Library/

Show hidden files in finder: beware though, this might result in a lot of information being displayed which is not needed.

defaults write com.apple.finder AppleShowAllFiles -bool YES

Show full paths in finder: it’s quite useful to know always where you are.

defaults write com.apple.finder _FXShowPosixPathInTitle -bool YES

.. and many more customisations are listed on http://secrets.blacktree.com/.

Alternatively, you can customise your mac to the bone without touching the console by downloading a free utility software called TinkerTool.

13. Get the Old Apple Mail Back

The new Apple Mail interface is quite slick, but I still have some problems adapting to it.

You can easily revert back to the old interface just by going to the Mail menu and choose Preferences. From there, click Viewing and you’ll find the options you want right at the top.

14. .. ? (still looking for it!)

 

]]> http://www.michelepasin.org/blog/2011/10/19/upgrading-to-lion-tips-and-tricks/feed/ 2 1643 http://www.michelepasin.org/blog/2011/02/08/installing-pil-on-djangostack-1-1-1/ http://www.michelepasin.org/blog/2011/02/08/installing-pil-on-djangostack-1-1-1/#comments Tue, 08 Feb 2011 12:16:20 +0000 http://www.michelepasin.org/blog/?p=1095 The popular Python Imaging Library (PIL) adds image processing capabilities to your Python interpreter. This library supports many file formats and provides powerful image processing and graphics capabilities. I normally use Bitnami Djangostack for most of my Django development, which doesn’t come with PIL installed by default so in this post I’m summing up what steps I’ve taken to get that up and running.

This is the preamble: I recently got a new desktop machine (an iMac Intel core i3) with the latest OS installed (10.6.4), so I had to re-install a whole bunch of stuff. In order to set up the new mac I used Migration Assistant. This neat piece of software cloned almost all I had on the previous machine onto the new one, and that worked just wonderfully. However I was expecting some troubles with low-level libraries.. and that just happened with PIL this morning. It costed a 2-3 hours headache but the web eventually stirred me in the right direction… in this post I’m just summarising how I got around the problem.

The problem: missing gcc compiler

Yeah, first of all, let’s make it clear what the problem was: I usually run my django projects using Bitnami Djangostack (a closed environment that includes ready-to-run versions of Apache, MySQL, PostgreSQL, SQLite, Python and Django and required dependencies). Today I needed to use PIL in a project of mine, so was trying to install it using easy_install within the stack:

bash-3.2$ easy_install PIL
Searching for PIL
Reading http://pypi.python.org/simple/PIL/
Reading http://www.pythonware.com/products/pil
Reading http://effbot.org/zone/pil-changes-115.htm
Reading http://effbot.org/downloads/#Imaging
Best match: PIL 1.1.7
Downloading http://effbot.org/media/downloads/PIL-1.1.7.tar.gz
Processing PIL-1.1.7.tar.gz
Running PIL-1.1.7/setup.py -q bdist_egg --dist-dir /var/folders/kd/kdz+WPeYFKik+eU2zVQ+tE+++TI/-Tmp-/easy_install-R5yISp/PIL-1.1.7/egg-dist-tmp-crzD37
WARNING: '' not a valid package name; please use only.-separated package names in setup.py
--- using frameworks at /System/Library/Frameworks
unable to execute gcc: No such file or directory
error: Setup script exited with error: command 'gcc' failed with exit status 1

Apparently the key error there is “unable to execute gcc: No such file or directory“. The installer can’t find the C compiler. Pretty weird cause I had already installed Xcode and all the rest (I ran the iPhone simulator a couple of days ago). I thought that maybe cloning the disk caused some unwanted file-renaming and so on… so I reinstalled Apple’s Developer Tools using the OS installation CD that came with the computer.
After 10 minutes of low screeches and CD-ROM loading, the installation was over and I had another go:

[mac]@macs-iMac:/Applications/djangostack-1.1.1-0/projects/ltb_project/src/ltb>usemydjangostack
bash-3.2$ easy_install PIL
Searching for PIL
Reading http://pypi.python.org/simple/PIL/
Reading http://www.pythonware.com/products/pil
Reading http://effbot.org/zone/pil-changes-115.htm
Reading http://effbot.org/downloads/#Imaging
Best match: PIL 1.1.7
Downloading http://effbot.org/media/downloads/PIL-1.1.7.tar.gz
Processing PIL-1.1.7.tar.gz
Running PIL-1.1.7/setup.py -q bdist_egg --dist-dir /var/folders/kd/kdz+WPeYFKik+eU2zVQ+tE+++TI/-Tmp-/easy_install-oET2AJ/PIL-1.1.7/egg-dist-tmp-Ptx6Q-
WARNING: '' not a valid package name; please use only.-separated package names in setup.py
--- using frameworks at /System/Library/Frameworks
cc1: error: unrecognized command line option "-Wno-long-double"
error: Setup script exited with error: command 'gcc' failed with exit status 1
bash-3.2$

Looked like I made some progress, as the error now seemed more specific: “cc1: error: unrecognized command line option “-Wno-long-double“”. The reason why this is happening goes beyond my knowledge, so in desperate need of a quick fix I started a long google-journey.
Luckily I soon ran into this post on stackOverflow “Xcode gcc exit status 1“. Essentially, it suggests to run setup.py using to an older gcc version (gcc-4.0). Tried that and it worked just fine!

Following some blog posts, on a hunch, I ran setup.py pointing to an older gcc version (gcc-4.0).

CC=’/usr/bin/gcc-4.0′ python setup.py build

The fix

After downloading the PIL library from here, I built it:

bash-3.2$ CC='/usr/bin/gcc-4.0' python setup.py build
running build
running build_py
running build_ext
--- using frameworks at /System/Library/Frameworks
building '_imaging' extension
/usr/bin/gcc-4.0 -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBJPEG -DHAVE_LIBZ -I/System/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/Headers -IlibImaging -I/Applications/djangostack-1.1.1-0/python/include -I/usr/local/include -I/usr/include -I/Applications/djangostack-1.1.1-0/python/include/python2.5 -c _imaging.c -o build/temp.macosx-10.4-i386-2.5/_imaging.o
_imaging.c:3017: warning: initialization from incompatible pointer type
_imaging.c:3077: warning: initialization from incompatible pointer type
/usr/bin/gcc-4.0 -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBJPEG -DHAVE_LIBZ -I/System/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/Headers -IlibImaging -I/Applications/djangostack-1.1.1-0/python/include -I/usr/local/include -I/usr/include -I/Applications/djangostack-1.1.1-0/python/include/python2.5 -c decode.c -o build/temp.macosx-10.4-i386-2.5/decode.o
/usr/bin/gcc-4.0 -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBJPEG -DHAVE_LIBZ -I/System/Library/Frameworks/Tcl.framework/Headers -
[......various other warnings........]

gcc -L/Applications/djangostack-1.1.1-0/common/lib -bundle -undefined dynamic_lookup build/temp.macosx-10.4-i386-2.5/_imaging.o build/temp.macosx-10.4-i386-2.5/decode.o build/temp.macosx-10.4-i386-2.5/encode.o build/temp.macosx-10.4-i386-2.5/map.o build/temp.macosx-10.4-i386-2.5/display.o build/temp.macosx-10.4-i386-2.5/outline.o build/temp.macosx-10.4-i386-2.5/path.o build/temp.macosx-10.4-i386-2.5/libImaging/Access.o build/temp.macosx-10.4-i386-2.5/libImaging/Antialias.o build/temp.macosx-10.4-i386-2.5/libImaging/Bands.o build/temp.macosx-10.4-i386-2.5/libImaging/BitDecode.o build/temp.macosx-10.4-i386-2.5/libImaging/Blend.o build/temp.macosx-10.4-i386-2.5/libImaging/Chops.o build/temp.macosx-10.4-i386-2.5/libImaging/Convert.o build/temp.macosx-10.4-i386-2.5/libImaging/ConvertYCbCr.o build/temp.macosx-10.4-i386-2.5/libImaging/Copy.o build/temp.macosx-10.4-i386-2.5/libImaging/Crc32.o build/temp.macosx-10.4-i386-2.5/libImaging/Crop.o build/temp.macosx-10.4-i386-2.5/libImaging/Dib.o build/temp.macosx-10.4-i386-2.5/libImaging/Draw.o build/temp.macosx-10.4-i386-2.5/libImaging/Effects.o build/temp.macosx-10.4-i386-2.5/libImaging/EpsEncode.o build/temp.macosx-10.4-i386-2.5/libImaging/File.o build/temp.macosx-10.4-i386-2.5/libImaging/Fill.o build/temp.macosx-10.4-i386-2.5/libImaging/Filter.o build/temp.macosx-10.4-i386-2.5/libImaging/FliDecode.o build/temp.macosx-10.4-i386-2.5/libImaging/Geometry.o build/temp.macosx-10.4-i386-2.5/libImaging/GetBBox.o build/temp.macosx-10.4-i386-2.5/libImaging/GifDecode.o build/temp.macosx-10.4-i386-2.5/libImaging/GifEncode.o build/temp.macosx-10.4-i386-2.5/libImaging/HexDecode.o build/temp.macosx-10.4-i386-2.5/libImaging/Histo.o build/temp.macosx-10.4-i386-2.5/libImaging/JpegDecode.o build/temp.macosx-10.4-i386-2.5/libImaging/JpegEncode.o build/temp.macosx-10.4-i386-2.5/libImaging/LzwDecode.o build/temp.macosx-10.4-i386-2.5/libImaging/Matrix.o build/temp.macosx-10.4-i386-2.5/libImaging/ModeFilter.o build/temp.macosx-10.4-i386-2.5/libImaging/MspDecode.o build/temp.macosx-10.4-i386-2.5/libImaging/Negative.o build/temp.macosx-10.4-i386-2.5/libImaging/Offset.o build/temp.macosx-10.4-i386-2.5/libImaging/Pack.o build/temp.macosx-10.4-i386-2.5/libImaging/PackDecode.o build/temp.macosx-10.4-i386-2.5/libImaging/Palette.o build/temp.macosx-10.4-i386-2.5/libImaging/Paste.o build/temp.macosx-10.4-i386-2.5/libImaging/Quant.o build/temp.macosx-10.4-i386-2.5/libImaging/QuantHash.o build/temp.macosx-10.4-i386-2.5/libImaging/QuantHeap.o build/temp.macosx-10.4-i386-2.5/libImaging/PcdDecode.o build/temp.macosx-10.4-i386-2.5/libImaging/PcxDecode.o build/temp.macosx-10.4-i386-2.5/libImaging/PcxEncode.o build/temp.macosx-10.4-i386-2.5/libImaging/Point.o build/temp.macosx-10.4-i386-2.5/libImaging/RankFilter.o build/temp.macosx-10.4-i386-2.5/libImaging/RawDecode.o build/temp.macosx-10.4-i386-2.5/libImaging/RawEncode.o build/temp.macosx-10.4-i386-2.5/libImaging/Storage.o build/temp.macosx-10.4-i386-2.5/libImaging/SunRleDecode.o build/temp.macosx-10.4-i386-2.5/libImaging/TgaRleDecode.o build/temp.macosx-10.4-i386-2.5/libImaging/Unpack.o build/temp.macosx-10.4-i386-2.5/libImaging/UnpackYCC.o build/temp.macosx-10.4-i386-2.5/libImaging/UnsharpMask.o build/temp.macosx-10.4-i386-2.5/libImaging/XbmDecode.o build/temp.macosx-10.4-i386-2.5/libImaging/XbmEncode.o build/temp.macosx-10.4-i386-2.5/libImaging/ZipDecode.o build/temp.macosx-10.4-i386-2.5/libImaging/ZipEncode.o -L/usr/local/lib -L/Applications/djangostack-1.1.1-0/python/lib -L/usr/lib -ljpeg -lz -o build/lib.macosx-10.4-i386-2.5/_imaging.so
ld: warning: in build/temp.macosx-10.4-i386-2.5/_imaging.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in build/temp.macosx-10.4-i386-2.5/decode.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in build/temp.macosx-10.4-i386-2.5/encode.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in build/temp.macosx-10.4-i386-2.5/map.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in build/temp.macosx-10.4-i386-2.5/display.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in build/temp.macosx-10.4-i386-2.5/outline.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in build/temp.macosx-10.4-i386-2.5/path.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in build/temp.macosx-10.4-i386-2.5/libImaging/Access.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in build/temp.macosx-10.4-i386-2.5/libImaging/Antialias.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in build/temp.macosx-10.4-i386-2.5/libImaging/Bands.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in build/temp.macosx-10.4-i386-2.5/libImaging/BitDecode.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in build/temp.macosx-10.4-i386-2.5/libImaging/Blend.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in build/temp.macosx-10.4-i386-2.5/libImaging/Chops.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in build/temp.macosx-10.4-i386-2.5/libImaging/Convert.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in build/temp.macosx-10.4-i386-2.5/libImaging/ConvertYCbCr.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in build/temp.macosx-10.4-i386-2.5/libImaging/Copy.o, file was built for i386 which is not the architecture being linked (x86_64)
[...various other warnings....]

building '_imagingtk' extension
creating build/temp.macosx-10.4-i386-2.5/Tk
/usr/bin/gcc-4.0 -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/System/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/Headers -IlibImaging -I/Applications/djangostack-1.1.1-0/python/include -I/usr/local/include -I/usr/include -I/Applications/djangostack-1.1.1-0/python/include/python2.5 -c _imagingtk.c -o build/temp.macosx-10.4-i386-2.5/_imagingtk.o -framework Tcl -framework Tk
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:78,
                 from _imagingtk.c:19:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:131: warning: function declaration isn~Rt a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:334: warning: function declaration isn~Rt a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:453: warning: function declaration isn~Rt a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:471: warning: function declaration isn~Rt a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:496: warning: function declaration isn~Rt a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:497: warning: function declaration isn~Rt a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:509: warning: function declaration isn~Rt a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:522: warning: function declaration isn~Rt a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1056: warning: function declaration isn~Rt a prototype
i686-apple-darwin10-gcc-4.0.1: -framework: linker input file unused because linking not done
i686-apple-darwin10-gcc-4.0.1: Tcl: linker input file unused because linking not done
i686-apple-darwin10-gcc-4.0.1: -framework: linker input file unused because linking not done
i686-apple-darwin10-gcc-4.0.1: Tk: linker input file unused because linking not done
/usr/bin/gcc-4.0 -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/System/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/Headers -IlibImaging -I/Applications/djangostack-1.1.1-0/python/include -I/usr/local/include -I/usr/include -I/Applications/djangostack-1.1.1-0/python/include/python2.5 -c Tk/tkImaging.c -o build/temp.macosx-10.4-i386-2.5/Tk/tkImaging.o -framework Tcl -framework Tk
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:78,
                 from Tk/tkImaging.c:51:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:131: warning: function declaration isn~Rt a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:334: warning: function declaration isn~Rt a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:453: warning: function declaration isn~Rt a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:471: warning: function declaration isn~Rt a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:496: warning: function declaration isn~Rt a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:497: warning: function declaration isn~Rt a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:509: warning: function declaration isn~Rt a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:522: warning: function declaration isn~Rt a prototype
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:1056: warning: function declaration isn~Rt a prototype
i686-apple-darwin10-gcc-4.0.1: -framework: linker input file unused because linking not done
i686-apple-darwin10-gcc-4.0.1: Tcl: linker input file unused because linking not done
i686-apple-darwin10-gcc-4.0.1: -framework: linker input file unused because linking not done
i686-apple-darwin10-gcc-4.0.1: Tk: linker input file unused because linking not done
gcc -L/Applications/djangostack-1.1.1-0/common/lib -bundle -undefined dynamic_lookup build/temp.macosx-10.4-i386-2.5/_imagingtk.o build/temp.macosx-10.4-i386-2.5/Tk/tkImaging.o -L/usr/local/lib -L/Applications/djangostack-1.1.1-0/python/lib -L/usr/lib -o build/lib.macosx-10.4-i386-2.5/_imagingtk.so -framework Tcl -framework Tk
ld: warning: in build/temp.macosx-10.4-i386-2.5/_imagingtk.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: in build/temp.macosx-10.4-i386-2.5/Tk/tkImaging.o, file was built for i386 which is not the architecture being linked (x86_64)
building '_imagingmath' extension
/usr/bin/gcc-4.0 -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/System/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/Tk.framework/Headers -IlibImaging -I/Applications/djangostack-1.1.1-0/python/include -I/usr/local/include -I/usr/include -I/Applications/djangostack-1.1.1-0/python/include/python2.5 -c _imagingmath.c -o build/temp.macosx-10.4-i386-2.5/_imagingmath.o
gcc -L/Applications/djangostack-1.1.1-0/common/lib -bundle -undefined dynamic_lookup build/temp.macosx-10.4-i386-2.5/_imagingmath.o -L/usr/local/lib -L/Applications/djangostack-1.1.1-0/python/lib -L/usr/lib -o build/lib.macosx-10.4-i386-2.5/_imagingmath.so
ld: warning: in build/temp.macosx-10.4-i386-2.5/_imagingmath.o, file was built for i386 which is not the architecture being linked (x86_64)
--------------------------------------------------------------------
PIL 1.1.7 SETUP SUMMARY
--------------------------------------------------------------------
version       1.1.7
platform      darwin 2.5.4 (r254:67916, Nov 24 2009, 10:46:19)
              [GCC 4.0.1 (Apple Computer, Inc. build 5250)]
--------------------------------------------------------------------
--- TKINTER support available
--- JPEG support available
--- ZLIB (PNG/ZIP) support available
*** FREETYPE2 support not available
*** LITTLECMS support not available
--------------------------------------------------------------------
To add a missing option, make sure you have the required
library, and set the corresponding ROOT variable in the
setup.py script.

To check the build, run the selftest.py script.
running build_scripts
creating build/scripts-2.5
copying and adjusting Scripts/pilconvert.py -> build/scripts-2.5
copying and adjusting Scripts/pildriver.py -> build/scripts-2.5
copying and adjusting Scripts/pilfile.py -> build/scripts-2.5
copying Scripts/pilfont.py -> build/scripts-2.5
copying and adjusting Scripts/pilprint.py -> build/scripts-2.5
changing mode of build/scripts-2.5/pilconvert.py from 644 to 755
changing mode of build/scripts-2.5/pildriver.py from 644 to 755
changing mode of build/scripts-2.5/pilfile.py from 644 to 755
changing mode of build/scripts-2.5/pilfont.py from 644 to 755
changing mode of build/scripts-2.5/pilprint.py from 644 to 755

Then I installed it:

bash-3.2$ CC='/usr/bin/gcc-4.0' python setup.py install
running install
running build
running build_py
running build_ext
--- using frameworks at /System/Library/Frameworks
--------------------------------------------------------------------
PIL 1.1.7 SETUP SUMMARY
--------------------------------------------------------------------
version       1.1.7
platform      darwin 2.5.4 (r254:67916, Nov 24 2009, 10:46:19)
              [GCC 4.0.1 (Apple Computer, Inc. build 5250)]
--------------------------------------------------------------------
--- TKINTER support available
--- JPEG support available
--- ZLIB (PNG/ZIP) support available
*** FREETYPE2 support not available
*** LITTLECMS support not available
--------------------------------------------------------------------
To add a missing option, make sure you have the required
library, and set the corresponding ROOT variable in the
setup.py script.

To check the build, run the selftest.py script.
running build_scripts
running install_lib
creating /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/__init__.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/_imaging.so -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/_imagingmath.so -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/_imagingtk.so -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ArgImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/BdfFontFile.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/BmpImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/BufrStubImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ContainerIO.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/CurImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/DcxImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/EpsImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ExifTags.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/FitsStubImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/FliImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/FontFile.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/FpxImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/GbrImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/GdImageFile.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/GifImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/GimpGradientFile.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/GimpPaletteFile.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/GribStubImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/Hdf5StubImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/IcnsImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/IcoImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/Image.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageChops.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageCms.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageColor.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageDraw.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageDraw2.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageEnhance.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageFile.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageFileIO.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageFilter.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageFont.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageGL.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageGrab.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageMath.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageMode.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageOps.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImagePalette.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImagePath.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageQt.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageSequence.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageShow.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageStat.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageTk.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageTransform.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImageWin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/ImtImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/IptcImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/JpegImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/McIdasImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/MicImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/MpegImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/MspImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/OleFileIO.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/PaletteFile.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/PalmImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/PcdImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/PcfFontFile.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/PcxImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/PdfImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/PixarImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/PngImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/PpmImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/PsdImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/PSDraw.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/SgiImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/SpiderImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/SunImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/TarIO.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/TgaImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/TiffImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/TiffTags.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/WalImageFile.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/WmfImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/XbmImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/XpmImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
copying build/lib.macosx-10.4-i386-2.5/XVThumbImagePlugin.py -> /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/__init__.py to __init__.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ArgImagePlugin.py to ArgImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/BdfFontFile.py to BdfFontFile.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/BmpImagePlugin.py to BmpImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/BufrStubImagePlugin.py to BufrStubImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ContainerIO.py to ContainerIO.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/CurImagePlugin.py to CurImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/DcxImagePlugin.py to DcxImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/EpsImagePlugin.py to EpsImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ExifTags.py to ExifTags.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/FitsStubImagePlugin.py to FitsStubImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/FliImagePlugin.py to FliImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/FontFile.py to FontFile.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/FpxImagePlugin.py to FpxImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/GbrImagePlugin.py to GbrImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/GdImageFile.py to GdImageFile.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/GifImagePlugin.py to GifImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/GimpGradientFile.py to GimpGradientFile.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/GimpPaletteFile.py to GimpPaletteFile.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/GribStubImagePlugin.py to GribStubImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/Hdf5StubImagePlugin.py to Hdf5StubImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/IcnsImagePlugin.py to IcnsImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/IcoImagePlugin.py to IcoImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/Image.py to Image.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageChops.py to ImageChops.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageCms.py to ImageCms.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageColor.py to ImageColor.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageDraw.py to ImageDraw.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageDraw2.py to ImageDraw2.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageEnhance.py to ImageEnhance.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageFile.py to ImageFile.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageFileIO.py to ImageFileIO.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageFilter.py to ImageFilter.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageFont.py to ImageFont.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageGL.py to ImageGL.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageGrab.py to ImageGrab.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageMath.py to ImageMath.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageMode.py to ImageMode.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageOps.py to ImageOps.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImagePalette.py to ImagePalette.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImagePath.py to ImagePath.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageQt.py to ImageQt.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageSequence.py to ImageSequence.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageShow.py to ImageShow.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageStat.py to ImageStat.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageTk.py to ImageTk.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageTransform.py to ImageTransform.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImageWin.py to ImageWin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImImagePlugin.py to ImImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/ImtImagePlugin.py to ImtImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/IptcImagePlugin.py to IptcImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/JpegImagePlugin.py to JpegImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/McIdasImagePlugin.py to McIdasImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/MicImagePlugin.py to MicImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/MpegImagePlugin.py to MpegImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/MspImagePlugin.py to MspImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/OleFileIO.py to OleFileIO.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/PaletteFile.py to PaletteFile.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/PalmImagePlugin.py to PalmImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/PcdImagePlugin.py to PcdImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/PcfFontFile.py to PcfFontFile.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/PcxImagePlugin.py to PcxImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/PdfImagePlugin.py to PdfImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/PixarImagePlugin.py to PixarImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/PngImagePlugin.py to PngImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/PpmImagePlugin.py to PpmImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/PsdImagePlugin.py to PsdImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/PSDraw.py to PSDraw.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/SgiImagePlugin.py to SgiImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/SpiderImagePlugin.py to SpiderImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/SunImagePlugin.py to SunImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/TarIO.py to TarIO.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/TgaImagePlugin.py to TgaImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/TiffImagePlugin.py to TiffImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/TiffTags.py to TiffTags.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/WalImageFile.py to WalImageFile.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/WmfImagePlugin.py to WmfImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/XbmImagePlugin.py to XbmImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/XpmImagePlugin.py to XpmImagePlugin.pyc
byte-compiling /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/XVThumbImagePlugin.py to XVThumbImagePlugin.pyc
running install_scripts
copying build/scripts-2.5/pilconvert.py -> /Applications/djangostack-1.1.1-0/python/bin
copying build/scripts-2.5/pildriver.py -> /Applications/djangostack-1.1.1-0/python/bin
copying build/scripts-2.5/pilfile.py -> /Applications/djangostack-1.1.1-0/python/bin
copying build/scripts-2.5/pilfont.py -> /Applications/djangostack-1.1.1-0/python/bin
copying build/scripts-2.5/pilprint.py -> /Applications/djangostack-1.1.1-0/python/bin
changing mode of /Applications/djangostack-1.1.1-0/python/bin/pilconvert.py to 755
changing mode of /Applications/djangostack-1.1.1-0/python/bin/pildriver.py to 755
changing mode of /Applications/djangostack-1.1.1-0/python/bin/pilfile.py to 755
changing mode of /Applications/djangostack-1.1.1-0/python/bin/pilfont.py to 755
changing mode of /Applications/djangostack-1.1.1-0/python/bin/pilprint.py to 755
running install_egg_info
Writing /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL/PIL-1.1.7-py2.5.egg-info
creating /Applications/djangostack-1.1.1-0/python/lib/python2.5/site-packages/PIL.pth

And that was it: djangostack’s python now has PIL available too:

bash-3.2$ python
Python 2.5.4 (r254:67916, Nov 24 2009, 10:46:19)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Image
>>> dir(Image)
['ADAPTIVE', 'AFFINE', 'ANTIALIAS', 'BICUBIC', 'BILINEAR', 'CONTAINER', 'CUBIC', 'DEBUG', 'EXTENSION', 'EXTENT', 'FLIP_LEFT_RIGHT', 'FLIP_TOP_BOTTOM', 'FLOYDSTEINBERG', 'ID', 'Image', 'ImageMode', 'ImagePalette', 'ImagePointHandler', 'ImageTransformHandler', 'IntType', 'LINEAR', 'MESH', 'MIME', 'MODES', 'NEAREST', 'NONE', 'NORMAL', 'OPEN', 'ORDERED', 'PERSPECTIVE', 'QUAD', 'RASTERIZE', 'ROTATE_180', 'ROTATE_270', 'ROTATE_90', 'SAVE', 'SEQUENCE', 'StringType', 'TupleType', 'UnicodeStringType', 'VERSION', 'WEB', '_E', '_ENDIAN', '_ImageCrop', '_MAPMODES', '_MODEINFO', '_MODE_CONV', '__builtins__', '__doc__', '__file__', '__name__', '_conv_type_shape', '_fromarray_typemap', '_getdecoder', '_getencoder', '_getscaleoffset', '_imaging_not_installed', '_initialized', '_show', '_showxv', '_wedge', 'blend', 'byteorder', 'composite', 'core', 'eval', 'fromarray', 'frombuffer', 'fromstring', 'getmodebandnames', 'getmodebands', 'getmodebase', 'getmodetype', 'init', 'isDirectory', 'isImageType', 'isNumberType', 'isSequenceType', 'isStringType', 'isTupleType', 'merge', 'new', 'open', 'os', 'preinit', 'register_extension', 'register_mime', 'register_open', 'register_save', 'string', 'sys', 'v', 'warnings']
>>>

Update 14/11/11: If you’re on 10.7 (Lion)

This recipy won’t work anymore on Lion because of the reasons pointed out in this stack-overflow article:

Xcode 4.1 on OS X Lion 10.7 no longer includes gcc-4.0 as it did in earlier versions of OS X. When you install a Python package like PIL that includes a C extension module, Python’s Distutils will attempt to use the same version of the C compiler that that Python itself was build with.

Too bad. It’s very easy to circumvent the problem.. just download PIL, start the stack as you would normally (./use_djangostack) and manually install the PIL package with python setup.py install.

Warning: this will work, but you’ll be able to use only some of the functionalities PIL offers. E.g.:

>>> import Image
# works just fine
>>> import _imaging
dlopen("/Applications/djangostack-1.3-0/python/lib/python2.6/site-packages/PIL/_imaging.so", 2);
Traceback (most recent call last):
  File "", line 1, in 
ImportError: dlopen(/Applications/djangostack-1.3-0/python/lib/python2.6/site-packages/PIL/_imaging.so, 2): no suitable image found.  Did find:
	/Applications/djangostack-1.3-0/python/lib/python2.6/site-packages/PIL/_imaging.so: mach-o, but wrong architecture

I order to understand what’s going on, you should remember that the PIL library consists of two main parts: a number of Python modules, usually stored in a PIL subdirectory, and a binary extension module called _imaging. Depending on platform and version, the latter is stored in a file named _imaging.pyd, _imaging.dll or _imaging.so (more info on all of this can be found here).

The error we got (“_imaging C module is not installed“) is caused by the fact that Lion uses a different C compiler than the one used for building the python libraries in your Djangostack. That had a cascade effect on the C-imaging libraries installed by PIL (for the reason mentioned above), which, as a result, can’t be run by Lion, and thus need to be updated.

The quick and dirty fix I used is this one: I installed again PIL outside the djangostack, and then copied over the newly generate C files back inside the stack. In other words, I installed again PIL using the latest C compiler that comes by default with Lion, and copied over only what I needed (the C libraries) into the stack.

That is: install PIL system-wide via the usual easy_install PIL. This will install the package in /Library/Python/2.7/site-packages/PIL-1.1.7-py2.7-macosx-10.7-intel.egg/. Then grab the files you need from there (e.g. _imaging.so, _imagingmath.so, _imagingtk.so) and put them into the djangostack python folder, which will be something like this: /Applications/djangostack-1.3-0/python/lib/python2.6/site-packages/PIL (obviously this location varies depending on where you originally installed djangostack).

That’s the end. It’s a dirty trick, but it worked for me!

References:

Installing the Python Imaging Library on Mac OS X Leopard

Installing PIL on Mac OS X Leopard virtualenv with easy_install

The GNU compiler collection on mac osX

-Wno-long-double discussion on google groups

MAC OSX Python build issues /w PIL (Imaging-1.1.7)

libjpeg and Python Imaging (PIL) on Snow Leopard

Xcode gcc exit status 1

 

]]> http://www.michelepasin.org/blog/2011/02/08/installing-pil-on-djangostack-1-1-1/feed/ 4 1095 http://www.michelepasin.org/blog/2011/01/14/setting-up-django-registration/ http://www.michelepasin.org/blog/2011/01/14/setting-up-django-registration/#comments Fri, 14 Jan 2011 14:16:06 +0000 http://www.michelepasin.org/blog/?p=1057 Django’s admin framework includes the basic functionalities for logging in and out of the admin site, but if you’re building a so-called ‘social’ application and want people to be able to sign-up, log in and thus benefit from additional site functionalities then you need to use a more generic ‘registration’ application. The good news is: most of the work has already been done, so it’s just a matter of putting things together correctly.

I found a nicely written blog post on this topic, so in what follows I’m just doing a re-cap of the main steps involved and adding some other useful info.

Before we start: what follows has been tested on Django 1.1 Django 1.3, Python 2.6 and MySQL (note: on 13/8/12 I revised this post so that the code would work on django 1.3 – many thanks to the folks who left comments and pointed out what needed to be updated!)

1) Install

Download the package from bitbucket and add it to your application directory (or put it somewhere else and then modify your python path as needed). Then add the ‘registration’ app to the installed_apps tuple in your settings.py:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.humanize',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.admin',
    # etc..
    'registration',
)

2) Syncdb

Do a quick syncdb from the console, which will result in one new table being created in the DB, ‘RegistrationProfile’. All it contains is its primary key, the ‘user’ key, and the ‘activation code’ fields. Now we’ve got the data structures needed for setting up the registration application!

> python manage.py syncdb

3) Setting.py

Create some registration settings in settings.py:

ACCOUNT_ACTIVATION_DAYS=7
EMAIL_HOST='localhost'
EMAIL_PORT=1023
EMAIL_HOST_USER='username'
EMAIL_HOST_PASSWORD='password'

Obviously you’ve got to change the settings above depending on your specific server setup (more information is available here or here). Also, see point 7 below if you’re just testing things out without a SMTP server available.

4) Urls.py

Include the required registration urls to your urls.py:

urlpatterns = patterns(",
  (r'^admin/', include('django.contrib.admin.urls')),
  (r'^accounts/', include('registration.urls')),
)

5) Templates

Add the registration templates to your django-templates directory. The django-registration package we downloaded earlier on doesn’t include any templates, but you can easily find some of them online (for example here).
Anyways, no need to do that: I took those templates and added some other ones too so to create the minimal working package that’ll get you going (that doesn’t include any fancy css styling but all the basic html stuff is there). You can download the templates here, expand the zip file and put it in templates/registration.

6) Done! Let’s recap..

We’re now ready to go. Let’s pause for a moment and recap what we achieved: we installed and activated django-registration, which sets up a whole bunch of new urls. These are divided into two groups:

a) /login, /logout, the two-step password change at password/change/ and password/change/done/; the four-step password reset at password/reset/, password/reset/confirm/, password/reset/complete/ and password/reset/done/.
This is the original URL specification source code (you can see it on bitbucket too) :

# from django-registration / registration / auth_urls.py
urlpatterns = patterns('',
                       url(r'^login/$',
                           auth_views.login,
                           {'template_name': 'registration/login.html'},
                           name='auth_login'),
                       url(r'^logout/$',
                           auth_views.logout,
                           {'template_name': 'registration/logout.html'},
                           name='auth_logout'),
                       url(r'^password/change/$',
                           auth_views.password_change,
                            {'template_name': 'registration/password_change_form.html'},
                           name='auth_password_change'),
                       url(r'^password/change/done/$',
                           auth_views.password_change_done,
                            {'template_name': 'registration/password_change_done.html'},
                           name='auth_password_change_done'),
                       url(r'^password/reset/$',
                           auth_views.password_reset,
                            {'template_name': 'registration/password_reset_form.html'},
                           name='auth_password_reset'),
                       url(r'^password/reset/confirm/(?P<uidb36>[0-9A-Za-z]+)-(?P<token>.+)/$',
                           auth_views.password_reset_confirm,
                            {'template_name': 'registration/password_reset_confirm.html'},
                           name='auth_password_reset_confirm'),
                       url(r'^password/reset/complete/$',
                           auth_views.password_reset_complete,
                            {'template_name': 'registration/password_reset_complete.html'},
                           name='auth_password_reset_complete'),
                       url(r'^password/reset/done/$',
                           auth_views.password_reset_done,
                            {'template_name': 'registration/password_reset_done.html'},
                           name='auth_password_reset_done'),
)

b) the second group of urls are /activate and /register:
This is the original URL specification source (see it on bitbucket) :

# django-registration / registration / backends / default / urls.py 
urlpatterns = patterns('',
                       url(r'^activate/complete/$',
                           direct_to_template,
                           { 'template': 'registration/activation_complete.html' },
                           name='registration_activation_complete'),
                       # Activation keys get matched by w+ instead of the more specific
                       # [a-fA-F0-9]{40} because a bad activation key should still get to the view;
                       # that way it can return a sensible "invalid key" message instead of a
                       # confusing 404.
                       url(r'^activate/(?P<activation_key>w+)/$',
                           activate,
                           { 'backend': 'registration.backends.default.DefaultBackend' },
                           name='registration_activate'),
                       url(r'^register/$',
                           register,
                           { 'backend': 'registration.backends.default.DefaultBackend' },
                           name='registration_register'),
                       url(r'^register/complete/$',
                           direct_to_template,
                           { 'template': 'registration/registration_complete.html' },
                           name='registration_complete'),
                       url(r'^register/closed/$',  # UNUSED
                           direct_to_template,
                           { 'template': 'registration/registration_closed.html' },
                           name='registration_disallowed'),
                        # this is the default django login module 
                       (r'', include('registration.auth_urls')),
                       )

7) Testing

If you’re testing things on a development server you might not have access to an SMTP server (needed to test the email-based registration process). In such a case you can still try out your application using a workaround. In your settings.py file change the registration settings with the following ones:

EMAIL_HOST = 'localhost'
EMAIL_PORT = 1025
EMAIL_HOST_USER = "
EMAIL_HOST_PASSWORD = "
EMAIL_USE_TLS = False
DEFAULT_FROM_EMAIL = 'testing@example.com'

Then open up another console window and run a temporary ‘dummy’ SMTP server with python:

bash-3.2$ python -m smtpd -n -c DebuggingServer localhost:1025

This local SMTP server remains there waiting for incoming messages. If now you go to /accounts/register/, fill out the form and hit ‘send’ you’ll see the registration email printed out in the console. Basically what happened is this: the ‘dummy’ python SMTP server we’ve just set up picked up django’s email-sending request and consequently printed out the email contents. If this is indeed what happened, it means that your code is working properly… and that you can use the url provided in the email to test the activation functionality too.

For example, here is what you would see in the console after registering:

---------- MESSAGE FOLLOWS ----------
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: Activate your djangoproject.com account - you have 2 days!
From: testing@example.com
To: michele.pasin@hotmail.com
Date: Wed, 12 Jan 2011 16:49:59 -0000
Message-ID: <20110112164959.3366.35638@mymac.local>
X-Peer: 127.0.0.1


Someone, hopefully you, signed up for a new account at djangoproject.com using this email address. If it was you, and you'd like to activate and use your
account, click the link below or copy and paste it into your web browser's address bar:

http://127.0.0.1:8000/accounts/activate/6342fca5ffd430a820be6d98acde6e59a4c2d29c/

If you didn't request this, you don't need to do anything; you won't receive any more email from us, and the account will expire automatically in two days.

------------ END MESSAGE ------------

Pasting the ‘activation’ url in your browser should allow you to complete the registration process and check the rest of your code.

Finally, keep in mind also that the django-registration application sends out emails that contain your site’s URL for the activation link, and that URL is dynamically determined using the ‘sites’ application (normally added via settings.py). By default, your domain name is listed as ‘example.com’, and the easiest way to change this is to log into the admin application and click on the ‘Sites’ link on the admin home page to get to the relevant entry.

===== ++ =====

Some other possibly useful links:

Fromt the Django website:

User authentication in django

Sending emails

From the Django book:

Chapter 12: Sessions, users, and registration

 

]]> http://www.michelepasin.org/blog/2011/01/14/setting-up-django-registration/feed/ 23 1057 http://www.michelepasin.org/blog/2010/12/01/installing-mercurial-on-osx-10-6-5/ http://www.michelepasin.org/blog/2010/12/01/installing-mercurial-on-osx-10-6-5/#comments Wed, 01 Dec 2010 20:30:29 +0000 http://www.michelepasin.org/blog/?p=1035 Mercurial is a free, distributed source control management tool. It efficiently handles projects of any size and offers an easy and intuitive. That’s what you read on its website, at least. I decided to give it a go mainly because I was looking forward to use a decentralized version control system for a couple of side projects I’m working on; moreover, because a friend pointed out that BitBucket (an online free code-hosting service based on Mercurial) has a free plan that doesn’t force you to make your projects public by default – like most other competitor services do. Free + private = time to test it!

Installation started by downloading and running the default installer. The instructions online are very detailed, so I tried to follow them.
However, after installing, I tried to run the hg command (which is how you invoke mercurial) but the following error kept coming up:

abort: couldn't find mercurial libraries in [/usr/platlib/Library/Python/2.6/site-packages /usr/local/bin /Library/Python/2.5/site-packages/ipython-0.9.1-py2.5.egg /Library/Python/2.5/site-packages/readline-2.5.1-py2.5-macosx-10.5-i386.egg /Library/Python/2.5/site-packages/antlr_python_runtime-3.1.1-py2.5.egg /Library/Python/2.5/site-packages/feedparser-4.1-py2.5.egg /Library/Python/2.5/site-packages/pydelicious-0.5.0-py2.5.egg /Library/Python/2.5/site-packages/virtualenv-1.3.3-py2.5.egg /Library/Python/2.5/site-packages/python_ldap-2.3.9-py2.5-macosx-10.5-i386.egg /Library/Python/2.5/site-packages/setuptools-0.6c11-py2.5.egg /Library/Python/2.5/site-packages/py2app-0.4.3-py2.5.egg /Library/Python/2.5/site-packages/macholib-1.2.1-py2.5.egg /Library/Python/2.5/site-packages/modulegraph-0.7.3-py2.5.egg /Library/Python/2.5/site-packages/yolk-0.4.1-py2.5.egg /Library/Python/2.5/site-packages/django_profiles-0.2-py2.5.egg /Library/Python/2.5/site-packages/pyglet-1.1.3-py2.5.egg /Library/Python/2.5/site-packages/PdbTextMateSupport-0.3-py2.5.egg /Library/Python/2.5/site-packages/PyXML-0.8.4-py2.5-macosx-10.5-i386.egg /Library/Python/2.5/site-packages/rdflib-3.0.0-py2.5.egg /Users/mac/Code/python/utils /Users/mac /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python25.zip /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5 /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-darwin /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac/lib-scriptpackages /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload /Library/Python/2.5/site-packages /Library/Python/2.5/site-packages/PIL /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/PyObjC /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/wx-2.8-mac-unicode]
(check your install and PYTHONPATH)

 

Fixing the errors

Mercurial couldn’t find the python libraries it needs to run; after a bit of googling I found out that installing Mercurial from the Mac Disk Image will cause its files to end up here:

/Library/Python/2.6/site-packages/

Apparently the default python installation that comes with 10.6.5 puts all the python packages somewhere else, that is, in the Frameworks directory:

/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages

That’s why Mercurial couldn’t find them – by default OSx expects python libraries to be somewhere else. Adding the missing library location to the pythonpath in ~/.bash_profile fixed that:

export PYTHONPATH="/Library/Python/2.6/site-packages:$PYTHONPATH"

Next step, adding the Mercurial config file at ~/.hgrc :

[mac]@yourname:~>touch .hgrc
[mac]@yourname:~>pico .hgrc
 # in the file add these lines:
[ui]
; editor used to enter commit logs, etc.  Most text editors will work.
editor = mate
username = MY_FIRST_NAME MY_LAST_NAME 

 

Getting started with BitBucket

Time to get started with setting up the BiBucket repository now. First set up an account on the site, then clone your repository with these commands:

[mac]@yourname:~/Some/location>hg clone https://yourname@bitbucket.org/name/repository_name
http authorization required
realm: Bitbucket.org HTTP
user: yourname
password: ******
destination directory: your_dir
no changes found
updating to branch default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

Almost there… next thing, add some files to the repository/directory, ‘add‘ them and ‘commit‘ them. You’re up and running..

[mac]@yourname:~/Some/location> hg add
adding -ideas/.DS_Store
adding -ideas/15June2010/untitled.scm
adding -ideas/15June2010/zeb1.patch
adding -ideas/15June2010/zeb2.patch
adding -ideas/15June2010/zeb3.patch
adding -ideas/15June2010/zeb4.patch
adding -ideas/a.scm
adding -ideas/a_better_drum_machine.scm
adding -ideas/a_progression.scm
adding -ideas/c-ColorChange.scm
adding -ideas/cassa_a_gogo.scm
adding -ideas/ccx-simple_progression.scm
adding -ideas/chords_with_drums.scm
..... etcetera....

[mac]@ yourname:~/Some/location>hg commit -m "Initial commit of all files to the repository."
[mac]@ yourname:~/Some/location>hg push # to push changes to this repo
http authorization required
realm: Bitbucket.org HTTP
user: yourname
password: ****
pushing to https://yourname@bitbucket.org/name/repository_name
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 455 changes to 455 files
remote: bb/acl: yourname is allowed. accepted payload.

 

GUIs

I also tried a couple of Graphical User Interfaces for Mercurial; the one that seemed best to me (on OSx obviously) is Murky, which is freely available here. Can’t ask for more can I?

UPDATE: Another quite nice (and free) user interface is MacHG.

 

]]> http://www.michelepasin.org/blog/2010/12/01/installing-mercurial-on-osx-10-6-5/feed/ 2 1035 http://www.michelepasin.org/blog/2010/11/17/preloading-stuff-in-djangos-interactive-shell/ http://www.michelepasin.org/blog/2010/11/17/preloading-stuff-in-djangos-interactive-shell/#comments Wed, 17 Nov 2010 18:41:07 +0000 http://www.michelepasin.org/blog/?p=1012 Django’s shell is a fantastic way to interact with all the components of your django application, eg when testing new functionalities or debugging a nasty error. Sometimes though you end up loading the same variables or importing the same modules every time you run the shell , for example because you are trying out a large function that needs being refined through a trial and error process.

Opening up the shell and reloading all the components you need to have handy can thus become a bit tedious; here’s an easy way to go around this problem.
In doing this, I’ve just been inspired some code found in the handy django-extensions app. The extensions ship with a number of command modules, that is, functions that you can run from the unix shell using the usual python manage.py some_command syntax.

The module I’m talking about here is called shell_plus – it’s an enhanced version of the Django shell. It will autoload all your models making it easy to work with the ORM right away. Here’s the implementation:

# django_extensions/management/commands/shell_plus.py



import os

from django.core.management.base import NoArgsCommand

from optparse import make_option



class Command(NoArgsCommand):

    option_list = NoArgsCommand.option_list + (

        make_option('--plain', action='store_true', dest='plain',

            help='Tells Django to use plain Python, not IPython.'),

        make_option('--no-pythonrc', action='store_true', dest='no_pythonrc',

            help='Tells Django to use plain Python, not IPython.'),

    )

    help = "Like the 'shell' command but autoloads the models of all installed Django apps."



    requires_model_validation = True



    def handle_noargs(self, **options):

        # XXX: (Temporary) workaround for ticket #1796: force early loading of all

        # models from installed apps. (this is fixed by now, but leaving it here

        # for people using 0.96 or older trunk (pre [5919]) versions.

        from django.db.models.loading import get_models, get_apps

        loaded_models = get_models()



        use_plain = options.get('plain', False)

        use_pythonrc = not options.get('no_pythonrc', True)



        # Set up a dictionary to serve as the environment for the shell, so

        # that tab completion works on objects that are imported at runtime.

        # See ticket 5082.

        from django.conf import settings

        imported_objects = {'settings': settings}

        for app_mod in get_apps():

            app_models = get_models(app_mod)

            if not app_models:

                continue

            model_labels = ", ".join([model.__name__ for model in app_models])

            print self.style.SQL_COLTYPE("From '%s' autoload: %s" % (app_mod.__name__.split('.')[-2], model_labels))

            for model in app_models:

                try:

                    imported_objects[model.__name__] = getattr(__import__(app_mod.__name__, {}, {}, model.__name__), model.__name__)

                except AttributeError, e:

                    print self.style.ERROR_OUTPUT("Failed to import '%s' from '%s' reason: %s" % (model.__name__, app_mod.__name__.split('.')[-2], str(e)))

                    continue

        try:

            if use_plain:

                # Don't bother loading IPython, because the user wants plain Python.

                raise ImportError

            import IPython

            # Explicitly pass an empty list as arguments, because otherwise IPython

            # would use sys.argv from this script.

            shell = IPython.Shell.IPShell(argv=[], user_ns=imported_objects)

            shell.mainloop()

        except ImportError:

            # Using normal Python shell

            import code

            try: # Try activating rlcompleter, because it's handy.

                import readline

            except ImportError:

                pass

            else:

                # We don't have to wrap the following import in a 'try', because

                # we already know 'readline' was imported successfully.

                import rlcompleter

                readline.set_completer(rlcompleter.Completer(imported_objects).complete)

                readline.parse_and_bind("tab:complete")



            # We want to honor both $PYTHONSTARTUP and .pythonrc.py, so follow system

            # conventions and get $PYTHONSTARTUP first then import user.

            if use_pythonrc:

                pythonrc = os.environ.get("PYTHONSTARTUP")

                if pythonrc and os.path.isfile(pythonrc):

                    try:

                        execfile(pythonrc)

                    except NameError:

                        pass

                # This will import .pythonrc.py as a side-effect

                import user

            code.interact(local=imported_objects)

Essentially, this is what’s going on here:

a. A subclass of NoArgsCommand is created following the standard approach stated in Django’s docs for creating custom management commands .

b. All the applications in your django project and the related models get loaded, and their references are added to the imported_objects dictionary, eg when the code reads:

imported_objects = {'settings': settings}

c. The code tries to load the best python shell available: iPython if present, otherwise the normal python shell with the necessary libraries are called.

…

That’s all. The key line to look at is therefore the last one, that is:

# .......
code.interact(local=imported_objects)

That’s what launches the interpreter and initializes it with the imported_objects dictionary; this dictionary contains all the (extra) symbols that we want to make available through the new python interpreter instance. So in order to have more stuff there all we have to do is add more elements to that dictionary, eg:

# .......
alist = range(1000)
imported_objects['alist'] = alist
code.interact(local=imported_objects)

Insert these two lines right before the last line of the script above, save it using a new name (eg. my_fancyshell.py )in the /management/commands/ directory of one of your applications (it needs to be there so that django interprets it as a custom command), and the game is done. Now you can invoke

bash-3.2$ python manage.py my_fancyshell.py

from the unix command line, and the ‘alist’ symbol will be available.
Obviously in a real world situation you might end up loading and adding to the imported_objects dictionary various many things too, but the principle will remain the same!

…

]]> http://www.michelepasin.org/blog/2010/11/17/preloading-stuff-in-djangos-interactive-shell/feed/ 3 1012