At the PIKTipi sprint this past weekend, Andi Zeidler, Andreas Jung and
I worked on integrating ZODB 3.8 and Zope 3.4 into the Zope 2 trunk.
Zope 3.4 has actually "exploded" into many eggs that are now
independently managed and released. I therefore looked into a way to
make Zope 2 dependent on these eggs instead of shipping with its own
copies of the packages. There are clear benefits to that:
* as newer versions of specific zope.* or ZODB packages are released,
you can individually install those or not. There'll be no need to wait
for another Zope 2 release.
* many third-party packages that we had to ship with Zope 2 were
actually dependencies of the included Zope 3 (pytz, ClientForm, etc.).
The Zope 3 eggs now simply depend on them via the egg dependency
mechanism, which means we no longer have to track those projects through
vendor imports.
* I actually went a bit further and eggified Zope 2 (it seemed the
logical conclusion). I didn't really explode Zope 2, it's one big egg
(except for a few things that are completely independent, such as
ExtensionClass, Acquisition, DateTime, zLOG). Though currently not very
comfortable to use, the Zope2 egg seems fully functional and I see it as
a (if not *the*) way to distribute Zope 2 in the future.
Coming to the actual problem: docutils is one third-party dependency of
Zope that we track as a vendor import. Due to certain security problems
that can arise when rendering reStructuredText, the docutils code was
patched. Therefore, when shipping Zope with the standard docutils
distribution (which can be conveniently pulled down as an egg), tests
that assert the security of reStructuredText obviously fail.
Andi converted the patch that was done to docutils to a monkey patch.
It's available on the 'witsch-zope2.11-with-standard-docutils' branch.
Not only am I not a big fan of monkey patches, I also think the
behaviour of failing with an exception instead of presenting a warning
is not very friendly.
Tres explained the reason for patching docutils to raise a
NotImplementedError in an email message on 8 July 2006:
In Zope2 land, the module is still available, and can be used by other
code (which may not know of that issue). I'm *not* in favor of shipping
an un-patched docutils until we work this out. For instance, perhaps we
should be patching docutils to make the *default* settings disable file
inclusion and 'raw'; then the trusted code which wanted to render reST
which legitimately needed those features could enable them explicitly.
In my 'philikon-zope2.11-with-standard-docutils' branch, I have done
that "working out": making all reStructuredText rendering from Zope
immune to 'include' and 'raw' directives. Instead of raising a
NotImplementedError, however, I simply changed the default settings in
docutils (via monkey patch that's much less intrusive than swapping out
methods).
I propose to merge my branch to the trunk, therefore effectively
changing the way we deal with the forbidden 'include' and 'raw'
directives (presenting warning, not raising NotImplementedError), and
allowing us to work with a standard docutils distribution.
If wanted, I'd also be willing to backport this to older Zopes, though
that might change their behaviour regarding reStructuredText in an
unwanted way within a bugfix release.
--
http://worldcookery.com -- Professional Zope documentation and training
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
