On 8/25/06, Martijn Faassen <[EMAIL PROTECTED]> wrote:
also wonder how easy it is to install something that's not shipped with
the core into the core.
From where I sit (behind fancy buildout systems!), it's just as easy
to add another separately-developed zope.something package as it is to
add a zc.something package. There are a number of non-core
zope.something packages on svn.zope.org now, and these definately see
use in one or more projects.
Yes, that makes sense, if you have a need to rely on one library or
another for the same API. I'm not sure whether this is an important
need, though... One could say this anticipates Python 2.5, but once
Python 2.5 is released and Zope starts to require it, making zope.webdav
use it could be as simple as just changing a few import statements anyway.
"Use" are "require" are distinct. We probably want to support Python
2.5 before we require it. That would be ideal, at any rate. My
interest is in keeping all the import dances out of application code;
I find them terribly distracting, and keeping the reasoning behind
specific aspects of such a dance straight can be difficult. This
isolates it from the application, avoiding duplication of the import
That said, it's probably also valuable *not* to exclude lxml.etree
from the dance so that applications don't accidentally become
dependent on the extended functionality. Or it could be wrapped to
prevent access to additional features, but that seems overkill.
Fred L. Drake, Jr. <fdrake at gmail.com>
"Every sin is the result of a collaboration." --Lucius Annaeus Seneca
Zope3-dev mailing list