Genshi works reliably for us, I'm with just saying that we keep it and
if needs changes, it's our job to make those changes, which will
hopefully kickstart (pun not intended) a new community to develop
Darren L. VanBuren
----- "Stephen John Smoogen" <smooge(a)gmail.com>
> On Thu, Apr 15, 2010 at 9:49 AM, Luke Macken <lmacken(a)redhat.com>
> > The future of Genshi is currently in question...
> > We currently rely on the Genshi templating engine for:
> > * all static fedoraproject.org
sites are compiled down to HTML
> from Genshi
> > * Elections
> > * FAS
> > * PackageDB
> > * Smolt
> > * Trac (which will be switching to Jinja2 in the next release)
> > It's also worth noting that Bodhi & Mirrormanager still rely on Kid,
> the unmaintained precursor to Genshi.
> > Quoting upstream:
> > """
> > Yes, my interests have mostly shifted elsewhere. I still believe
> that both Babel and Genshi are worth being further maintained and
> enhanced, and I'm still interested to actually do the work, but
> obviously I'm not able to allot anywhere enough spare time to that
> task right now. What's more, I've unforunately been unable to attract
> other developers to contribute significantly to either code base, let
> alone build a strong community. That's not to say that I consider
> either project end-of-life. I still use them for my own stuff. But I'm
> the pretty much the single point of failure for both projects, and
> I've been failing badly and consistently at maintaining/enhancing them
> for some time now. Sorry.
> > I agree that adoption of Jinja2 should be considered, it's become a
> very solid templating solution, and comes with both more momentum and
> better performance than Genshi. But I'm not sure how a gradual
> transition could work. As Noah said, you can't switch some of the most
> important pages to Jinja and still support stream filters. Or site
> templates using match templates for advanced customization. You'll
> also need to rethink parts of the internationalization story, I
> > If there's going to be another template engine switch, I think it's
> going to hurt. But it might just be worth it.
> > """
> > So, what are our options?
> > 1) Find contributors that are willing and able to help sustain this
> project upstream
> > 2) Stay on Genshi and rely on the Fedora/EPEL maintainers to fix
> bugs as they are filed
> > 3) Try and utilize http://pypi.python.org/pypi/chameleon.genshi
> instead, which is supposed to be able to run Genshi templates faster
> than Genshi can.
> > (Note: TG2 was going to support this engine, but apparently it
> needs a bit more work. It may still be worth looking into, though.)
> > 4) Port to another templating engine (Jinja2, Mako, etc)
> > We obviously have a vested interest in keeping this project alive,
> so #1 is ideal.
> > Porting will require a bit of effort. The TurboGears2 port of bodhi
> that I'm working on will use the Mako templating engine (which is
> actively maintained by the SQLAlchemy author). However, it seems
> we've taken the #2 route with Kid for the past 5 years, and I've had
> zero issues with it.
> > There was talk at PyCon this year about changing the TurboGears2
> default templating engine to Mako. The only reason not to for 2.0 was
> to ease the 1.0->2.0 transition. However, everyone I spoke to was in
> favor of switching the defaults in 2.1.
> Looking at the options and other parts.. I think staying with Genshi
> for the most part would be our 'best' bet. If someone is really
> motivated or if we are doing a huge code change in something then
> maybe it would be attractive for changing.
Yeah, I agree. This issue has caused a lot of discussion today, and there are definitely
a lot of people out there that care about Genshi
and some have even stepped up and are willing to help support & maintain it. I also
see some milestone activity on my upstream tickets happening today.
So, Genshi is definitely not dead -- it just needed a swift kick in the ass :)
infrastructure mailing list