[Zope-dev] Why third_party/docutils?
jim at zope.com
Mon Nov 29 17:24:42 EST 2004
Andreas Jung wrote:
> --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
>> 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
I don't understand what good moving it would do for it's ease of maintenance.
> 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
But there's no point in making things more complicated. I see no benefit
in this extra directory. Am I missing something?
> Using a sitecustomize.py appeared as the best
> solution compared to hacking runzope/zopectl or added some paths
> somewhere inside the Zope startup machinery).
I'll have more to say in a separate message.
Jim Fulton mailto:jim at zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
More information about the Zope-Dev