If you’ve used easy_install and setup.py before, you may have noticed that running something like “easy_install -d PATH” versus “python setup.py install PATH” produce different directory hierarchies. If your development environment consists of both packages pulled from the Cheeseshop and your own code (or even your modifications on Cheeseshop hosted packages), then you need a way to put packages from both installation methods into the same path.
It turns out that easy_install can take a tar.gz file as an argument. So, you can take a package foo that has a setup.py defined, create a foo.tar.gz of the directory containing setup.py and all the associated code, then run “easy_install -d PATH foo.tar.gz”, which will create the egg and install it for you in the proper way, alongside your Cheeseshop pulled packages.
We’ve officially released CyLucene, a Python interface to CLucene. CLucene is a C++ implementation of Apache Lucene, the popular search engine library.
Python developers wishing to use a well supported search engine typically head to PyLucene. PyLucene’s approach is to build an interface to a C++ layer using their custom grown JCC compiler, which then talks to Java Lucene via JNI. That’s two layers of indirection, one of which is JNI.
Even if you believe JNI is efficient, there’s still the added overhead of requiring Java at runtime. If you run a website on a shared hosting service that restricts you to, say, 80 MB of RAM, CyLucene might be for you.
CyLucene 0.1 is minimally useful. It good enough to power Standing Room’s upcoming search features, but it’s far from a complete CLucene bridge. We’re in real need of feedback as to what features we need to expose to make the package more generally useful. You can find contact info in the readme.txt file, and can file a bug as always.
Very glad to see named tuples!
When I was a Python n00b (maybe I still am?), I asked on Stack Overflow whether or not such a feature existed. I received one particularly arrogant response, in my opinion, along the lines of “why insist that your code looks like C++? It destroys my Python zen.”
That comment is contrary to one reason why I’ve become such a Python fan — the design and community is the optimal balance of sanity for my tastes.
Other languages of this genre that I’ve used are Ruby, Lua, and Scheme.
Ruby is beautiful, but the community is blinded by that fact.
Lua is a little too hurriedly practical, sprinkled with language quirks that are hard to keep track of for an occasional programmer.
And Scheme… oh, Scheme, such wasted potential. It had 20 years lead time to become the Python of our age, and countless numbers of computer science students indoctrinated via SICP. But even with those advantages, scrappy little brother Python is the one that took the limelight.
Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
I’m excited to announce the first official free software release by S7 Labs! I wrote Opid to replace the AuthKit module for OpenID authentication in Standing Room. AuthKit, built for the Pylons framework, provided more functionality than I was looking for, and proved to be difficult to customize. Opid is orders of magnitude smaller in code size and more flexible, IMO, though it leaves a user model implementation up to the developer. Check it out!
The Beaker documentation mentions that you can use a file backed session backend, along with numerous other methods (memory, dbm, various SQL flavors, even Google App Engine datastore).
What they don’t explain is how you actually use a file backend, and searching around was turning up nothing. It turns out to be similar to how you configure Beaker caching, a la with data and lock directories:
session_app = beaker.middleware.SessionMiddleware(app,
type='file',
data_dir='/path/to/some/dir',
lock_dir='/path/to/another/dir')
We use pkgsrc to maintain a consistent set of development sources across OS X, FreeBSD, Debian, and other Linux distributions. pkgsrc works reasonably well, has a decently large repository of packages (relatively easy to add a new package), active development, and is mostly portable.
Note: what follows is really only interesting if you’re looking into using pkgsrc, otherwise it’ll make you yawn. I’m writing this because I found little information on the web to help me out, and I wanted to make sure others don’t repeat my mistakes.
One portability problem we encountered was the use of sqlite3 with python25. When linking python25 against pkgsrc’s sqlite3 on OS X, we’d get “Non-aligned pointer being freed” errors, along the lines of this thread. In the thread, one person suggested to use the native sqlite3 library if it exists.
This was deeply unsatisfying to me. I was convinced there was simply some argument I had to pass into the sqlite3 build to make it magically work on OS X.
(This would suggest to me that pkgsrc’s sqlite3 on OS X is broken. Is the upstream sqlite3 broken as well?)
Alas, it broke me, and after hours of wasted time, I simply modified the pkgsrc python25 makefile to check for the existence of a native sqlite3:
.if !exists(/usr/include/sqlite3.h) .include "../../databases/sqlite3/buildlink3.mk" .endif
Not totally correct (I ignore version checking), but it works for the systems I care about anyway.
There’s a subtle point I should mention here. pkgsrc sets up a special build/link environment for packages based on what other packages the target depends on. For example, if the python25’s pkgsrc makefile includes sqlite3’s buildlink3.mk, then pkgsrc sets up an environment for python25 that contains a series of symlinks in work/.buildlink/lib to the sqlite3 libraries in the pkgsrc installation tree. The compiler and linker generally includes system library paths on its own, so what you’re left with is the possibility to build against pkgsrc’s sqlite3, or the system sqlite3 if it exists. If pkgsrc’s sqlite3 is installed, then that’s the package that takes precedence.
In the case of FreeBSD, the native (ie, ports) version of sqlite3 gets installed into /usr/local, which is not automatically included in the link path. As a result, the build of python25 will not link against any valid version of sqlite3 in the absence of adding pkgsrc’s sqlite3 to its dependency list. What’s worse, there’s no obvious error. The Python build system allows you to enable sqlite3, but doesn’t abort the build if no sqlite3 exists. You’re left with “No _sqlite3.so in /usr/lib/python2.5/lib-dynload” type errors unless you include sqlite3 as a dependency in the python25 package.
Once you understand how pkgsrc works, it seems like it’d be a great tool to eliminate multiple packaging problems. That said, I dream of the day that FreeBSD’s ports system can be made portable enough to eliminate the need for pkgsrc. I know that pkgsrc is a fork of ports, but it’s nowhere near as complete. There’s more value in having a packaging system with lots of packages than one with advanced features (IPS, I’m looking at you). Number of packages goes hand in hand with number of users; number of users goes hand in hand with ease of locating packages. That’s a chicken and egg problem here that’s very hard for an upstart packaging system to solve. I honestly don’t think that MacPorts or DarwinPorts is worth the effort — it’s completely counter productive to build a packaging system that works conceptually like ports or pkgsrc, but isn’t actually ports or pkgsrc.
Anyway, end rant.
