python-fedex 0.1 Released

After a few weeks of slow work, I finally have released python-fedex.This module is a very light wrapper around suds and the Fedex WSDLs. There is very little abstraction, the idea is just to handle the annoying WSDL stuff behind-the-scenes and raise some basic exceptions if really bad things happen.

By figuring out the suds+WSDL end of things, I hope to allow other Python developers to jump into their projects much more quickly. This will be used in a production environment at IP, and will see extensive testing starting in a few weeks.

If you are at all interested or curious, see the python-fedex Google Code page.

MacPorts Python 2.6 + Snow Leopard

I just thought I’d provide a friendly heads up to the Django and Pythoncommunities that the Python 2.6 distributed with MacPorts does not compile on Snow Leopard as of now. This issue is outlined on MacPorts ticket #20284.

There are some really hacky work-arounds, but they are not for the feint of heart. This is reportedly an upstream Python problem, and has been reported as such by the MacPorts community. While Python 2.6 is included with Snow Leopard, MacPython requires its own Python26 package for many other things.

Other than that, Snow Leopard has been great. This is not a complete show-stopper since you can just manually install stuff, but it is somewhat annoying.

Django + EVE Online

For the use of fellow Djangonauts out there, I introspected and fixed upCCP’s SQL dump of EVE Online data. This means you can now get access to everything from the comforts of the Django ORM.

The project is still very new, and I’m not even sure it’s going to be attractive given the table layout. At this point, it is a bunch of introspected models and a fixed up database dump. I’ll be adding convenience methods, __unicode__ functions, and etc with time to make it more friendly. Check it out at:

http://code.google.com/p/django-eve/

For now this will only work on Postgres until some kind soul wants to get the MySQL or SQLite dumps fixed up (some tables need ‘id’ primary keys).

Lack of an open X-Rite i1 (Eye-One) SDK

After doing a lot of work with the X-Rite (formerly Gretagmacbeth) i1(Eye-One) Pro SDK, I’ve started running into strange little quirks with their close-sourced libraries. The documentation is decent, but severely lacking in crucial areas such as code examples. Several of the functions are vaguely defined with no examples whatsoever. To make matters worse, there is absolutely no developer community since the SDK isn’t publicly available.

So if you’re running on a platform other than Windows or Mac OSX, you’re generally out of luck. There is a rudimentary set of drivers that an open source color profiling library has implemented, but it does not handle many of the features and not nearly as well as the X-Rite SDK. Fortunately, I’ve been able to at least abstract some of the quirks away by writing a Python wrapper around their C library, but there are still some things that would be high on the list for improvement if the Eye-One SDK were publicly available.

It is a pity this stuff is kept under such tight wraps. I’m not sure if they realize, but X-Rite could be promoting a flourishing community of developers rather than squashing any code examples on the net and not even hosting a rudimentary communication device such as a mailing list for people to share their work and ask questions. Perhaps they fear the software people would create if the tools were better documented and help was available. Maybe it’d challenge their monopoly and it’d be a bad thing.

Who knows, I guess.