namedtuple, classes and dictionaries are no longer the only options to represent a key/value mapping where all they keys are known upfront: Records may be a better alternative and they’re now available in Python via PyRecord.
Yes, I’m alive.
Since the second half of last summer I’ve been inactive in the Free Software arena. No commits, no emails from me in the last few months which may indicate that the projects are dead. So I wanted to write to let you know that I have no plans to stop maintaining any of my projects. I will start to catch up with all the things I’ve missed in the projects I normally contribute to and the projects I develop alone.
The reason why you’d heard nothing from me is that I left Spain to move to Oxford, in order to work at the cool company behind 2degreesnetwork.com. The removal was the most time-consuming and stressful thing I’d ever done, but after one month working here, I’m happy to say that it was worth it. The atmosphere is just like I thought Web 2.0 companies were, and I am surrounded by nice and talented people. I can’t be happier.
Well, back to the projects, I had to wait a lot to get access to the Internet at home, but I got it a couple of weeks ago and have been catching up (slowly) with the pending stuff. I still have a huge stack of unanswered emails, for example.
For the last couple of weeks I was working fulltime on repoze.what 1.1 and repoze.what-django. I hope to finish the documentation and get the first alpha releases out very soon; the code itself is pretty much ready and, as usual, fully tested. I didn’t have plans to do a repoze.what 1.1 release anytime soon, but while developing repoze.what-django I found myself implementing something which would be useful outside Django (i.e., ACLs) and thus I decided to move it to repoze.what.
After that, I want to improve the auth documentation in TurboGears 2. repoze.what-pylons is the crucial part of the repoze.what integration in TG2 and it’s fully documented, but duplicating part of those docs won’t do any harm and adding some tips and tricks would be nice. I started doing that some months ago but never committed it; I have to finish it this time.
Then I’d like to make repoze.what-pylons take advantage of the new features in repoze.what 1.1, like repoze.what-django already does.
Some weeks ago I was invited to make repoze.who.plugins.ldap an official repoze.who plugin, which means that:
- The license will change. It will use Repoze’s.
- The development tools will be migrated from Launchpad (bug tracker, repository, etc).
- The LDAP plugin’s documentation will be included into repoze.who’s.
- It will be maintained by Repoze commiters, and I’m one of them.
I’ve not started the migration, but I hope to start in a few days.
repoze.who.plugins.ldap is an straightforward yet powerful solution to enable LDAP authentication in your WSGI application. It enables you to have LDAP authentication working in your new or existing applications, in few minutes and with few lines of code!
It’s a plugin for the repoze.who framework, featuring not only an LDAP authenticator, but also related utilities. It’s a fully documented project which also ships with a working demo application, so it’d be hard for you to get stuck.
I wrote this plugin in order to enable LDAP authentication in Animador. And in fact, it’s the first application that uses the plugin.
The latest version is 1.0, and you’re highly encouraged to play with it and give feedback!
This is because I’ve been contributing patches for TurboGears 2 and other packages used by Animador (a TurboGears 2 application), since I started its development, in order to fix bugs and/or add new features that I want in Animador. So now I can apply my changes by myself!
And stay tunned, because very soon it’s going to be very easy to add OpenId support to any WSGI application by means of a plugin for the framework-independent repoze.who package!