[Zope-dev] Re: Why third_party/docutils?
Andreas Jung wrote: You're still not getting the point. Z2 shipped and Z3 ships with a *stripped* down version of Docutils where only the docutils subfolder is used. Now the *whole* package is included which makes it necessary to adjust the paths. Moving this as a whole to lib/python does *not* solve the need to adjust the path using sitecustomize.py or by adding paths to runzopefriends. I don't get this. Why couldn't we just delete the *entire* stripped-down 'docutils' package and replace it with the *whole* package *in exactly the same location*? E.g. (assuming we had not already munged things): $ cd Zope-2.7-branch/lib/python/docutils $ find . -type f | grep -v CVS | xargs cvs rm -f $ cvs commit -m - Blow away stripped down docutils. $ tar xzf /tmp/docutils-the-whole-enchilada.tar.gz $ find . -type f | grep -v CVS | xargs cvs add $ cvs commit -m - Add current docutils. What would break (or would have broken) had we done that? Another option would be to remove the 'docutils' directory *in the CVS repository and replace it with a symlink to the canonical vendor import. Docutils should be kept *somewhere* as a *whole* which makes updating much easier. Moving the package to lib/python does *not* solve Stefans problem which is maybe only a problem on Stefan's side (I don't know). The problem is that having to munge sitecustomize.py or the PYTHONPATH in order to get 'lib/python/thirdparty' included messes up *lots* of things. I would appreciate it if people in the community could come up with reasonable proposals and ideas how to solve problems instead of fighting against solutions being made. Especially the Z2 community is currently in a state where there is much talking and crying of people about Z2 issues that sux or must be resolved but there is really only a small, small of people really doing something substantial work. So looking back at this issue: the solution is working except for Stefan and if there is a problem anyone should suggest a reasonable problem or just fix the original problem (maintainability of Docutils) in a better way than I did. Otherwise we should keep it as it is or revert to an older version that has not the problems. But in this case I won't care about Docutils in future versions. The solution is *not* working; it addes complexity and brittleness, for little gain that anybody else can see. Jim has already pointed this fact out, and asked for an explanation of the rationale. Let's work out something which: - allows us to use the canonical version of docutils - doesn't impose unneeded restrictions on how people configure the Python with which they run Zope. Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com ___ 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 )
[Zope-dev] Re: Why third_party/docutils?
Andreas Jung wrote: --On Freitag, 17. Dezember 2004 11:34 Uhr -0500 Tres Seaver [EMAIL PROTECTED] wrote: Andreas Jung wrote: I don't get this. Why couldn't we just delete the *entire* stripped-down 'docutils' package and replace it with the *whole* package *in exactly the same location*? E.g. (assuming we had not already munged things): $ cd Zope-2.7-branch/lib/python/docutils $ find . -type f | grep -v CVS | xargs cvs rm -f $ cvs commit -m - Blow away stripped down docutils. $ tar xzf /tmp/docutils-the-whole-enchilada.tar.gz $ find . -type f | grep -v CVS | xargs cvs add $ cvs commit -m - Add current docutils. If you unpack Docutils as a whole in lib/python then you will a structure lib/python/docutils/docutils ^^ This is the directed where docutils import usually start. If you do adjust sys.path to lib/python/docutils/docutils then every code that tries to import the docutils package will fail because it tries to import from lib/python/docutils instead from lib/python/docutils/docutils. I don't know why this is so hard to understand or are we talking about different things? OK, then suppose we vendor import the docutils tarball into a different location, e.g.: $ cd /tmp $ tar xzf docutils-the-whole-enchilada.tar.gz $ cd dodcutils $ cvs -d :ext:cvs.zope.org:/cvs-repository import \ Libraries/docutils docutils docutils-0_xxx and then symlink the actual package portion in the CVS repository into Zope/lib/python? For SVN, we would spell that somewhat differently, but the idea would be the same. The major goal is to remove the need to jigger either the Python search path or the sitecustmize.py package; both of those practices step on territory which is intended to belong to the system admin, rather than the software. Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com ___ 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 )
[Zope-dev] Re: Why third_party/docutils?
Dieter Maurer wrote: Andreas Jung wrote at 2004-11-29 12:59 +0100: 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). A much clearer approach (than sys.path tweaking) would be to modify the imports for docutils: from docutils import ... to from third_party.docutils import ... While I approve in theory of such a rename, the problem in practice will be if docutils *itself* uses absolute imports. Guido's long-standing hostility to improving relative imports will bite us again, here. I expect docutils use is quite local. Outside the package itself, only zREST depends on it, I think. Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com ___ 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 )
