[docutils was moved from lib/python/docutils to lib/python/third_party/docutils/docutils and an ugly sys.path hack employed]

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?

Stefan


-- 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/

_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
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 )

Reply via email to