[Zope-dev] Why third_party/docutils?
Stefan H. Holek
stefan at epy.co.at
Mon Nov 29 06:43:02 EST 2004
[docutils was moved from lib/python/docutils to
lib/python/third_party/docutils/docutils and an ugly sys.path hack
Why oh why do we always have to make it harder to start up Zope
(instead of making it simpler, for once)?
Extending the path in lib/python/sitecustomize only works if lib/python
is on the PYTHONPATH at the time the interpreter is started. This is
fine in case of ./bin/zopectl, but not anywhere else. For example it
breaks basically all test runners. Yes, I have seen that test.py got
hacked to append third_party/docutils to the sys.path, this is however
not a solution IMO, but plain cheating around a code layout error.
test.py is *not* the only test runner around, nor is ./bin/zopectl the
only way to start up Zope!
Many a sysadmin will curse at having to "fix" a whole bunch of scripts.
We have been very careful in the past to accommodate them, let me
remind you of the ZOPE_CONFIG hack we added just for legacy scripts.
What is the reason for third_party? Is is absolutely required, and if
yes, why? Why not keep it simple (well, as simple as possible given the
already tricky Z2 startup sequence)?
I'd be very happy if this decision could be reconsidered. Thoughts?
The time has come to start talking about whether the emperor is as well
dressed as we are supposed to think he is. /Pete McBreen/
More information about the Zope-Dev