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?