Compiling a universal library

A note for my future self on how to compile a library as universal binary in Mac OS X.

For a while, I’ve been getting warnings like these when building pymssql:

ld: warning: ignoring file /usr/local/lib/libsybdb.dylib, 
file was built for unsupported file format 
( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) 
which is not the architecture being linked (i386): 
/usr/local/lib/libsybdb.dylib
ld: warning: ignoring file /usr/local/lib/libct.dylib, 
file was built for unsupported file format 
( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) 
which is not the architecture being linked (i386): 
/usr/local/lib/libct.dylib

I finally decided to do something about them. I rebuilt FreeTDS from source as follows:

./configure \
    CFLAGS="-arch i386 -arch x86_64" \
    CXXFLAGS="-arch i386 -arch x86_64" \
    LDFLAGS="-arch i386 -arch x86_64" \
    --disable-dependency-tracking
make
make install

Goodbye warnings!

This Stack Overflow post was helpful: Stack Overflow: How to compile universal libraries on Mac OS X?

Back to setuptools

Browsing PyPI yesterday, I was surprised to see a new version of setuptools. I almost thought it was a bug. For years, I’ve been drinking the distribute Kool-Aid

pip/distribute Public Service Announcement

and automatically using distribute instead of setuptools. Well, I guess that things have changed and now distribute has been merged into setuptools and distribute is deprecated and setuptools is the thing to use. It may take me a little while to unlearn my old habits and it might make explaining Python packaging a little bit more difficult (not that it was easy :-)).

Getting double-tap to drag working again in OS X Lion and Mountain Lion

Finally fixed one little thing that was annoying me on my work laptop with OS X 10.8.4. I couldn’t double-tap to drag files or make selections.

The fix is dead simple and it’s from this CNET article:

If you want to reactivate the classic double-tap-and-drag gesture, it’s possible, but the option is well-hidden. Instead of being in System Preferences under Trackpad, it’s actually under System Preferences > Universal Access > Mouse and Trackpad > Trackpad Options. Click the check box that says “Dragging” and you should be all set.

In Mountain Lion, it seems that “Universal Access” was renamed to “Accessibility”.

How to bring back "double tap to drag" in newer versions of OS X

How to bring back “double tap to drag” in newer versions of OS X

Note to self: Don’t name my git branches “tests”

I have sometimes had a git branch called “tests” because I was adding tests or working on tests. The problem is that many projects have a “tests” directory so if you have a “test” branch, you get this:

$ git diff tests
fatal: ambiguous argument 'tests': both revision and filename
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'

You can of course use git diff -- tests and it will work, but it’s easier to just not name a branch “tests” in the first place.

Plone and Zope time

Doing my yearly ritual of looking at Plone & Zope and making sure I still don’t grok them. Check.

In this year’s installment, I set up a little Plone site and actually got as far as creating a custom content type. I started down the road of thinking I would create the content type manually with code in Archetypes. Then I looked at tutorials and saw that it looked like it involved a lot of repetitive code and configuration voodoo. I ended up using ZopeSkel to create a really, really simple Archetypes content type, which actually didn’t take too long to figure out (to my pleasant surprise).

It still feels like too much work and it’s difficult to find good documentation on what’s the current recommended way to do things, because the recommended way of doing things seems to change every couple of years and there is a lot of old, outdated documentation out there. A search on Archetypes for instance yielded all kinds of pages referring to practices that seem to be outdated now, like manually creating the directory structure for an Archetypes product (i.e.: no ZopeSkel) and copying the product into the Zope 2 “Products” directory (which seems to be deprecated in favor of buildout)

In comparison, creating a model in Django is very simple, Pythonic, and well-documented.

Continuation of mod_wsgi setup

My previous setup worked until I wanted to add another Django instance and then it didn’t work, because I had two WSGIScriptAlias entries under different URLs but it would launch whichever app it wanted to regardless of the URL. A little searching suggested that it had to do with mod_wsgi process pools. I eventually ended up with something like this:

WSGIPythonHome /www/python/pypi.venv
WSGIPythonPath /www/python/django
WSGIPassAuthorization On
WSGISocketPrefix /var/run/wsgi

<VirtualHost *:80>

    ...

    DocumentRoot /www/python

        WSGIDaemonProcess djangoplayground_wsgi user=apache python-path=/www/python/django
        WSGIScriptAlias /djangoplayground /www/python/django/djangoplayground/wsgi.py
        <Location /djangoplayground>
            WSGIProcessGroup djangoplayground_wsgi
        </Location>

        WSGIDaemonProcess djangopypi_wsgi user=apache python-path=/www/python/django
        WSGIScriptAlias /djangopypi /www/python/django/djangopypisite/wsgi.py
        <Location /djangopypi>
            WSGIProcessGroup djangopypi_wsgi
        </Location>
</VirtualHost>

djangotestxmlrpc

I had been working on DjangoPyPI and trying to fix some tests related to XML-RPC that were failing in versions of Python < 2.7, because the testing was relying on specifics of the implementation of xmlrpclib in Python 2.7. I found some code at this blog post from Forest Bond that showed a better way to test XML-RPC views in Django, namely, by creating a special XML-RPC transport object that uses the Django test client. I extracted this out and tweaked it slightly to add tests and better compatibility across Python versions and published it on PyPI as…


djangotestxmlrpc

Build Status

Test Django XML-RPC views using the Django test client. Because you’re using the Django test client, you’re not actually sending HTTP requests and don’t need a server running.

Example usage:

from djangotestxmlrpc import DjangoTestClientXMLRPCTransport

class TestXmlRpc(django.test.TestCase):
    ...

    def test_list_package(self):
        pypi = xmlrpclib.ServerProxy(
            "http://localhost/pypi/",
            transport=DjangoTestClientXMLRPCTransport(self.client))
        pypi_hits = pypi.list_packages()
        expected = ['foo']
        self.assertEqual(pypi_hits, expected)

Supported Python versions

  • Python 2.5
  • Python 2.6
  • Python 2.7
  • PyPy 1.9
  • Python 3.1
  • Python 3.2

or says tox:

~/dev/git-repos/djangotestxmlrpc$ tox
...
  py25: commands succeeded
  py26: commands succeeded
  py27: commands succeeded
  pypy: commands succeeded
  py31: commands succeeded
  py32: commands succeeded
  congratulations :)

You also can check the latest Travis CI results, but Travis doesn’t build all of the above platforms.

Issues

Send your bug reports and feature requests to https://github.com/msabramo/djangotestxmlrpc/issues