[Zope-dev] Why third_party/docutils?

[Andreas Jung]

--On Montag, 29. November 2004 12:43 Uhr +0100 "Stefan H. Holek" 
<stefan at epy.co.at> wrote:

> [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!

I agree.

>
> 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)?

It has been moved there because older Zope versions shipped with a stripped
down and hacked docutils version which fit into the path magic. But this
version was hard to maintain and it was a pain in the a** to update the
package from time to time. That's why it moved as a whole into a different
location. Independent of its location there is a need to adjust sys.path
to make imports working (it does not matter if it is under lib/python or
lib/python/third_party). Using a sitecustomize.py appeared as the best
solution compared to hacking runzope/zopectl or added some paths
somewhere inside the Zope startup machinery). But patches
(before the next 2.7.4 beta release) are welcome :-)

Andreas