TurboGears 2 in debian ... soon !

After a long incubation, a few days ago TurboGears 2 has been released. Historically, I've been preferring TurboGears over Django for being closer to the open source philosophy of reusing existing components.

Since the long 2.0 release was marking a gap with Django, I was eager to test the 2.0, and I was delighted to find it in Debian. Unfortunately, it doesn't seem to be in good shape yet. In particular it lacks several dependencies before it can even be used to quickstart a project, in spite of its presence in unstable.

To give an idea of the needed work, after having installed it manually (via easy_install), my virgin /usr/local/lib/python2.5/site-packages/ has been polluted by 26 egg-thingies. I decided to spend some week-end time to start closing the gap, because we cannot lack such an important web framework in Debian (and ... erm, yes, also because I need it :-) ).

Here is the current status of what has been ITP-ed / packaged already (by yours truly):

Where to

Considering, foolishly, the last package as being already done, the way to go is still long:

    zack@usha:~$ ls /usr/local/lib/python2.5/site-packages/|grep -v repoze.what
    AddOns-0.6-py2.5.egg
    BytecodeAssembler-0.3-py2.5.egg
    Catwalk-2.0.2-py2.5.egg
    easy-install.pth
    Extremes-1.1-py2.5.egg
    PEAK_Rules-0.5a1.dev_r2582-py2.5.egg
    prioritized_methods-0.2.1-py2.5.egg
    sprox-0.5.5-py2.5.egg
    sqlalchemy_migrate-0.5.2-py2.5.egg
    SymbolType-1.0-py2.5.egg
    tg.devtools-2.0-py2.5.egg
    tgext.admin-0.2.4-py2.5.egg
    tgext.crud-0.2.4-py2.5.egg
    TurboGears2-2.0-py2.5.egg
    tw.forms-0.9.3-py2.5.egg
    WebFlash-0.1a9-py2.5.egg
    zope.sqlalchemy-0.4-py2.5.egg

Possibly, some of them are already in Debian hidden somewhere, but sure there is still work to be done. If you want to help, you are more then welcome. The rules are simple: all packages will be maintained under the umbrella of the Python Modules Team, but you should be willing to take responsibility as the primary maintainer.

Please get in touch with if you are interested, as I'm in turn already in touch with some other very kind volunteers (thanks Enrico and Federico2!) to coordinate who-is-doing-what.

Preview packages available

What has already been packaged, including a temporary workaround for python-transaction, will be available in experimental after NEW processing. The idea is that nothing will go to unstable until TurboGears 2 will be (proven to be) fully functional.

In the meantime, packages are available from my personal APT repository (signed by my key), here are the friendly /etc/apt/sources.list :

    deb http://people.debian.org/~zack/debian zack-unstable/
    deb-src http://people.debian.org/~zack/debian zack-unstable/

Versions are tilde-friendly and shouldn't get in your way when the official packages will hit unstable.

Packaging multiple-egg / multiple-upstream packages

In all this, I've faced an interesting problem with the python-repoze.{who,what}-plugins packages. They correspond to a handful of plugins, each of which is about 20/30 Kb. I didn't consider appropriate to prepare 5 different packages, due to archive bloat potential. Hence, you get the usual problems of multiple-upstream packages.

To counter some of them, as well as some egg-specific packaging annoyances with multiple upstream, I wrote a couple of very simple helpers:

  • get-orig-source.mk (live version): a debian/rules snippet which relies on several debian/*.watch files which are fed to uscan to implement (not yet completely) the get-orig-source target described in policy

  • setup.py (live version): a multiplexer for sub-directories shipping distutils-enabled Python modules. That way you can use /usr/share/cdbs/1/class/python-distutils.mk as usual, and setup.py will take care of the "multiple upstream" problem at build time

I'm no Python-packaging-guru so, lazyweb, if you spot in this choice something I utterly overlooked, or if you have improvements to suggest, please let me know.

Repacking eggs

An interesting problem will be faced in trying to integrate the above approach with Python modules that are shipped only as .egg files (i.e., no tarballs, ... yes there are such horrifying things out there). To preserve uniformity, we would need uscan to support --repack ing of .egg files as they were simple .zip archives.

Since eggs are .zip archives ... why not?

turbogears2 looks so ... dirty & verbose?

Take a look at the 20 minute turbogears2 tutorial. Compare it to the Django tutorial.

Why does it all looks so cryptic and verbose compared to django?

Comment by jan Sun 31 May 2009 11:10:40 AM CEST
watch files for multi-source-tarball packages
Along similar lines to your get-orig-source snippet, do you have any ideas about how to generate debian/watch that does something sensible for packages with several upstream tarballs? Fetching new versions isn't so much the issue as e.g. integration into DEHS.
Comment by David Bremner Sun 31 May 2009 01:24:43 PM CEST
re: watch files for multi-source-tarball packages

Along similar lines to your get-orig-source snippet, do you have any ideas about how to generate debian/watch that does something sensible for packages with several upstream tarballs? Fetching new versions isn't so much the issue as e.g. integration into DEHS.

Unfortunately no, and that's why I hacked up my snippet. Personally, I think it would be totally worth to add to uscan support for downloading multiple tarball, but I understand that it would change some design choices and that not all current features will have sense with multiple tarballs. Maybe it can be made easier to work on multiple watch files, as my snippet does. I haven't checked the devscripts manpage (yet) to look for similar wishlist reports.

Comment by zack Sun 31 May 2009 03:21:00 PM CEST
Debconf
Are you going to be at the Debconf/Debcamp? I was going to look into packaging TG2 and making a guide for packaging web software developed in TG2. It would be a good place to hammer it out and release something usable to unstable.
Comment by aigarius.com Mon 01 Jun 2009 12:31:32 PM CEST
Re: Debconf

Yes, I'll be at debconf9 as well as debcamp, starting from July 18th.

... but it is is a month and a half for now: I hope to be able to hit unstable earlier than that (also because I need it sooner :-) )

Comment by zack Tue 02 Jun 2009 10:04:45 AM CEST