My whole EuroPython experience was a little disjointed, starting with arrival. I and one other delegate ended up on a bus that went, not to CERN but to a local railway station three or four kilometers away. The result was a late arrival, so by the time I took my place in this session Kevin was just starting to present his first example, how to adapt a simple application to the WSGI interface.
Using simple_app was the easiest, but Kevin also showed us how to do it by defining our own class. He then considered the problem of maintaining session state (though Kevin says he prefers not to use state).
WSGI is also helpful in such situations: its concept of middleware (which talks to the web server on one side and a web application on the other) can help. The example here was of a "Latinator" that translated into pig Latin. Kevin showed us how to define a class with a method that can be passed to the WSGI framework as the start_response argument. WSGI is good because there have been many contributions to the PyPI index.
Kevin next introduced us the the Paste system designed by Ian Bicking. This contains a confusing number of packages and modules, which makes it hard to describe and hard to climb the learning curve and start using it. He suggested this demonstrated that even in the Open Source world we are faced with the "build vs. buy" choice, even though "buy" is really an investment in learning someone else's package and build, as usual, is learning and understanding the base technologies you want to implement, and writing your own implementation.
In TurboGears Kevin made the choice to use as much existing technology as was practicable.
The fictitious web package author might decide to package up other dependencies, but this can cause problems for people with other versions of the components she chooses to bundle. This is the classic version dependency. The setuptools system has defined a cross-platform format for installation of Python packages, the .egg format. This can also be used to install packages with binary components, and is proving to be very usable.
The .egg format allows other systems to read the metadata about the package, which is useful in many environments where plugins are used, even in non-Python environments such as Eclipse. The discussion about how entry points were defined to plugins didn't seem terribly easy to understand to me - maybe I was just distracted by the extraneous materials, but I didn't really see the point.
Kevin closed by talking about Beaker, starting by showing us theat it depended on the MyghtyUtils package and defined two paste entry points. The examples at this stage started to leave me wishing I had attended the AJAX session instead, but this could just be me: others might have found the material relevant to their interests.
This presentation relied for contrast on rather too much use of "humourous" slides: a picture of an egg when talking about eggs, a picture of an RJ45 plug in a socket when talking about plugins. I have no objection to such devices, but they should either enhance understanding or be shown for a very short time to give everyone a quick smile before moving on.
Kevin knows his stuff and is always an engaging speaker. A tour de force, though, should really be allocated an hour, and I suspect this session should have covered more ground in less detail or vice versa.
"Any sufficiently advanced technology is indistinguishable from magic" -- Arthur C Clarke
Musings from the technological frontier
2 comments:
I think Kevin's last name is Dangoor, not Djangoor. Though that wouldn't be a bad name to have if he was the creator of Django, rather than TurboGears. :)
Regarding entry points, the whole idea of an entry point is just that it's a way for a package to provide a well-defined reference point that other packages can hook into, without knowing in advance where to import something from.
For example, Turbogears can support any Python templating language to generate web pages. You just have to create a package that registers an entry point saying basically "if the template type is 'kid', use this class to implement it".
This isn't a new idea for Python, but the part that *is* new is that just *installing* the package that offers the entry point is enough. If you create a package that implements the TurboGears templating interface for language foo, then installing the package's egg on your system automatically makes that template type available, without needing to first import the package. Instead, it allows TurboGears to ask, "is there any package installed that supports template type foo?" And it will automatically get back the right class to handle that type of template.
So, it's a very simple concept, but it's well-integrated into the installation process for eggs, and it makes extensible applications and frameworks a lot easier to develop.
But if you are one person writing a Python program and you don't expect to collaborate with other teams or third-party developers, you may not ever feel a need for it, or even see what the point is (no pun intended).
Thanks for the enlightenment (both on Kevin's name and on entry points). I've corrected the post title.
Post a Comment