W. Martin Borgert skrev 07. april 2010 23:23:
On 2010-04-07 17:02, Christian Boos wrote:
But if it's still not released in a month or so from now, then we
could indeed integrate the genshi/ files as tracdep/genshi.* and
make sure that the Trac plugins importing the genshi modules will
actually find our tracdep.genshi ones (hopefully a
`sys.modules['genshi'] = tracdep.genshi` will be enough).
I think, this model is not an option for Debian nor for most
other Linux distributions. Debian, and surely others as well,
work very hard on removing embedded code copies. Adding a new
copy would be a stop in the wrong direction. Embedded code
copies make QA work, especially security fixes, very hard. Also,
they bloat the archive. They constitute a policy violation in
Debian. It would be preferable to find an alternative solution.
Warning: it might be a bit to early in the day for me to be posting this
-- if anything below looks confrontational that's *not* intended...
I'm a bit confused -- why wouldn't we just slap a 0.6 on genshi, and
place it under the trac umbrella ?
As far as I understand, the alternative is for genshi to stagnate, and
not be packaged at all ? Do we really expect trac to need/introduce
incompatible changes to genshi ?
On Debian Stable I get:
> $ aptitude search '?depends(python-genshi)'
p lazygal Static web gallery generator
p python-creoleparser Parser for the Creole common wiki markup
language
p trac Enhanced wiki and issue tracking system for
software development projects
Looking at sid/unstable as well yields the following additional packages:
p python-django-genshi Django integration for Genshi
p python-relatorio Python module to create reports from Python
objects
p python-sponge Sponge is a web framework built on top of
CherryPy and Genshi
p python-turbogears2 Python web application framework
p tryton-server Tryton Application Platform (Server)
Most of these projects seem a little stale to me -- not entirely sure
about genshi and turbogears though ?
As I see this, genshi would benefit from being tested with one big,
real-world project (trac) -- and there's no real reason to *embed* it --
now that all the infrastructure needed to support it as an external egg
is available ?
I'm not saying we should "steal" genshi, but it really seems like 0.12
will need a new 0.6 release of genshi either way -- and releasing a new
"major" version seems cleaner than any other option.
Not familiar enough with pypi-dependencies to know how several version
interact (as far as I know it's not possible/advisable to simply
easy_install genshi-0.5 *and* genshi-0.6 for example?).
Anyway, I think there are three seperate issues, that all warrant
discussion:
a) Is the speed of genshi doomed due to genshis design? And if so,
should we for *speed reasons* give up on genshi ?
b) Are there resources available within the trac community to
provide adequate support for genshi for trac's needs (and
thereby better support than is available for any other
present or future project using genshi) ?
c) Does genshi's stream-filters provide enough of an advandage
to push for b) over a) ?
After looking at some of the genshi code examples on the wiki, I really
like what I see -- and think genshi have a lot going for it. If it's too
slow to be usable *due to design issues* -- I suppose the discussion
simply should be: *when* do we move to another system?
Note: I use the term "we" here -- although I've yet to contribute a
single line of code -- so take everything above with an extra grain of
salt...
Best regards,
--
.---. Eirik Schwenke <[email protected]>
( NSD ) Harald Hårfagresgate 29 Rom 150
'---' N-5007 Bergen tlf: (555) 889 13
GPG-key at pgp.mit.edu Id 0x8AA3392C
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
