[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 mailing list