[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/
--On Montag, 29. November 2004 12:43 Uhr +0100 "Stefan H. Holek" <stefan@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
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 ... I expect "docutils" use is quite local. -- Dieter
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 tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Andreas Jung wrote:
--On Montag, 29. November 2004 12:43 Uhr +0100 "Stefan H. Holek" <stefan@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.
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 lib/python/third_party).
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).
Ick. I'll have more to say in a separate message. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Just for a note: This just made me spend more than two very annoying hours debugging and fixing the zopeservice.py. Those changes are not meant to be done on a stable branch ... Am Montag, den 29.11.2004, 12:43 +0100 schrieb Stefan H. Holek:
[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)?
*Going for beer to save my sanity* Theuni -- gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - ct@gocept.com - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development
--On Donnerstag, 16. Dezember 2004 19:28 Uhr +0100 Christian Theune <ct@gocept.com> wrote:
Just for a note: This just made me spend more than two very annoying hours debugging and fixing the zopeservice.py. Those changes are not meant to be done on a stable branch ...
I disagree because maintaining Docutils in the state as they were in former version was a real pain. Cleaning up the mess was therefore a valid option and since this change happened during two final releases things (zopeservice) were only broken in beta 1 and 2 (that's why we have betas *wink*). Also no one came up so far with a better solution so I regard the reorganization as a suitable solution. But I am of course further improvements are very welcome :-) Any volunteers? .-) Andreas
*sound of me protesting noisily* Let me remind you of the Pope's decree: http://mail.zope.org/pipermail/zope-dev/2004-November/024073.html Stefan On 16. Dez 2004, at 20:14, Andreas Jung wrote:
--On Donnerstag, 16. Dezember 2004 19:28 Uhr +0100 Christian Theune <ct@gocept.com> wrote:
Just for a note: This just made me spend more than two very annoying hours debugging and fixing the zopeservice.py. Those changes are not meant to be done on a stable branch ...
I disagree because maintaining Docutils in the state as they were in former version was a real pain. Cleaning up the mess was therefore a valid option and since this change happened during two final releases things (zopeservice) were only broken in beta 1 and 2 (that's why we have betas *wink*). Also no one came up so far with a better solution so I regard the reorganization as a suitable solution. But I am of course further improvements are very welcome :-) Any volunteers? .-)
Andreas
-- 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/
--On Donnerstag, 16. Dezember 2004 20:30 Uhr +0100 "Stefan H. Holek" <stefan@epy.co.at> wrote:
*sound of me protesting noisily*
Let me remind you of the Pope's decree: http://mail.zope.org/pipermail/zope-dev/2004-November/024073.html
I have not seen a proposal so far how to solve this issue that works with a complete Docutils package and without sitecustomize.py and I don't know about a better solution. Having Docutils in sane state from the maintenance prospective is much more important for me than leaving it as it was. Andreas
Andreas Jung wrote at 2004-12-16 20:47 +0100:
*sound of me protesting noisily*
Let me remind you of the Pope's decree: http://mail.zope.org/pipermail/zope-dev/2004-November/024073.html
I have not seen a proposal so far how to solve this issue that works with a complete Docutils package and without sitecustomize.py and I don't know about a better solution.
What problems are solved by (mere) moving "DocUtils" into a "third_party" package that stay when it is one level up? Providing Zope's own "sitecustomize.py" interferes with site customizations usually maintained in the site's "sitecustomize.py". At least, this needs prominent warning notes: Zope now shadows any "sitecustomize.py" that may be in effect in your Python installation. Move any relevant definitions to Zope's "sitecustomize.py". A "*.pth" file might be an alternative to a "sitecustomize.py" (although "*.pth" has issues, too). -- Dieter
Andreas Jung wrote:
--On Donnerstag, 16. Dezember 2004 20:30 Uhr +0100 "Stefan H. Holek" <stefan@epy.co.at> wrote:
*sound of me protesting noisily*
Let me remind you of the Pope's decree: http://mail.zope.org/pipermail/zope-dev/2004-November/024073.html
I have not seen a proposal so far how to solve this issue that works with a complete Docutils package and without sitecustomize.py and I don't know about a better solution. Having Docutils in sane state from the maintenance prospective is much more important for me than leaving it as it was.
As I said in one of my responses to this thread, I see no problem that this extra directory solves. Could you please explain what problem you think an extra directory will solve? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
--On Donnerstag, 16. Dezember 2004 15:34 Uhr -0500 Jim Fulton <jim@zope.com> wrote:
Andreas Jung wrote:
--On Donnerstag, 16. Dezember 2004 20:30 Uhr +0100 "Stefan H. Holek" <stefan@epy.co.at> wrote:
*sound of me protesting noisily*
Let me remind you of the Pope's decree: http://mail.zope.org/pipermail/zope-dev/2004-November/024073.html
I have not seen a proposal so far how to solve this issue that works with a complete Docutils package and without sitecustomize.py and I don't know about a better solution. Having Docutils in sane state from the maintenance prospective is much more important for me than leaving it as it was.
As I said in one of my responses to this thread, I see no problem that this extra directory solves. Could you please explain what problem you think an extra directory will solve?
Stefan complained about the sitecustomize.py file and the additional paths injected inside the file. Moving docutils as a whole to lib/python would not solve the problem with similar adjustments to sys.path. So sitecustomize.py is the issue and not the location. Andreas
Andreas Jung wrote:
--On Donnerstag, 16. Dezember 2004 15:34 Uhr -0500 Jim Fulton <jim@zope.com> wrote:
Andreas Jung wrote:
--On Donnerstag, 16. Dezember 2004 20:30 Uhr +0100 "Stefan H. Holek" <stefan@epy.co.at> wrote:
*sound of me protesting noisily*
Let me remind you of the Pope's decree: http://mail.zope.org/pipermail/zope-dev/2004-November/024073.html
I have not seen a proposal so far how to solve this issue that works with a complete Docutils package and without sitecustomize.py and I don't know about a better solution. Having Docutils in sane state from the maintenance prospective is much more important for me than leaving it as it was.
As I said in one of my responses to this thread, I see no problem that this extra directory solves. Could you please explain what problem you think an extra directory will solve?
Stefan complained about the sitecustomize.py file and the additional paths injected inside the file. Moving docutils as a whole to lib/python would not solve the problem with similar adjustments to sys.path.
AFAICT, the problem is that you made a change that requires lots of scripts to be modified and become slightly more complicated. This is not a huge deal if there's a good reason for it, but I can't figure out what that reason could be. See below.
So sitecustomize.py is the issue and not the location.
Why is docutils in third_party? Stefan asked this before. You answered: "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." This answer doesn't make any sense to me. What does changing the docutils version have to do with it's location. Zope 3 has docutils in lib/python, why can't Zope 2? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
--On Donnerstag, 16. Dezember 2004 16:01 Uhr -0500 Jim Fulton <jim@zope.com> wrote:
Andreas Jung wrote:
--On Donnerstag, 16. Dezember 2004 15:34 Uhr -0500 Jim Fulton <jim@zope.com> wrote:
Andreas Jung wrote:
--On Donnerstag, 16. Dezember 2004 20:30 Uhr +0100 "Stefan H. Holek" <stefan@epy.co.at> wrote:
*sound of me protesting noisily*
Let me remind you of the Pope's decree: http://mail.zope.org/pipermail/zope-dev/2004-November/024073.html
I have not seen a proposal so far how to solve this issue that works with a complete Docutils package and without sitecustomize.py and I don't know about a better solution. Having Docutils in sane state from the maintenance prospective is much more important for me than leaving it as it was.
As I said in one of my responses to this thread, I see no problem that this extra directory solves. Could you please explain what problem you think an extra directory will solve?
Stefan complained about the sitecustomize.py file and the additional paths injected inside the file. Moving docutils as a whole to lib/python would not solve the problem with similar adjustments to sys.path.
AFAICT, the problem is that you made a change that requires lots of scripts to be modified and become slightly more complicated. This is not a huge deal if there's a good reason for it, but I can't figure out what that reason could be. See below.
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 runzope&friends. 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). 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. Andreas
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 runzope&friends.
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 tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Andreas Jung wrote:
--On Donnerstag, 16. Dezember 2004 16:01 Uhr -0500 Jim Fulton <jim@zope.com> wrote:
Andreas Jung wrote:
--On Donnerstag, 16. Dezember 2004 15:34 Uhr -0500 Jim Fulton <jim@zope.com> wrote:
Andreas Jung wrote:
--On Donnerstag, 16. Dezember 2004 20:30 Uhr +0100 "Stefan H. Holek" <stefan@epy.co.at> wrote:
*sound of me protesting noisily*
Let me remind you of the Pope's decree: http://mail.zope.org/pipermail/zope-dev/2004-November/024073.html
I have not seen a proposal so far how to solve this issue that works with a complete Docutils package and without sitecustomize.py and I don't know about a better solution. Having Docutils in sane state from the maintenance prospective is much more important for me than leaving it as it was.
As I said in one of my responses to this thread, I see no problem that this extra directory solves. Could you please explain what problem you think an extra directory will solve?
Stefan complained about the sitecustomize.py file and the additional paths injected inside the file. Moving docutils as a whole to lib/python would not solve the problem with similar adjustments to sys.path.
AFAICT, the problem is that you made a change that requires lots of scripts to be modified and become slightly more complicated. This is not a huge deal if there's a good reason for it, but I can't figure out what that reason could be. See below.
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.
Please explain why including all of docutils requires adjusting the paths. We include all of docutils in Zope 3 and don't adjust the paths. We *did* adjust docutils slightly. Is the version in Zope 3 less complete than the one you want to include in Z2? If not, I suggest copying that one, as it works for Zope 3. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
--On Montag, 20. Dezember 2004 7:36 Uhr -0500 Jim Fulton <jim@zope.com> wrote:
Please explain why including all of docutils requires adjusting the paths.
I did that already in an earlier mail last week.
We include all of docutils in Zope 3 and don't adjust the paths. We *did* adjust docutils slightly.
No, Zope 3 ships only with the 'docutils' subdirectory of the Docutils package. -aj
Andreas Jung wrote:
--On Montag, 20. Dezember 2004 7:36 Uhr -0500 Jim Fulton <jim@zope.com> wrote:
Please explain why including all of docutils requires adjusting the paths.
I did that already in an earlier mail last week.
You may think you did.
We include all of docutils in Zope 3 and don't adjust the paths. We *did* adjust docutils slightly.
No, Zope 3 ships only with the 'docutils' subdirectory of the Docutils package.
What is it lacking? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
[Jim Fulton]
We include all of docutils in Zope 3 and don't adjust the paths. We *did*adjust docutils slightly.
[Andreas Jung]
No, Zope 3 ships only with the 'docutils' subdirectory of the Docutils package.
[Jim]
What is it lacking?
I suppose it's the 'docs', 'extras', 'licenses' and 'tools' subdirectories, although I see that the 'tools' subdirectory checked in on Zope-2_7-branch was stripped of its GPL'ed pieces first. Andreas, does Zope 2 *use* any of the stuff in the non-docutils subdirectories? Jim, while I personally don't care much, Zope3's repackaging of docutils doesn't meet license requirements to retain the original licenses in derivative works. Zope2's does, because it includes docutil's whole 'licenses' subdirectory (except for the GPL).
Tim Peters wrote: ...
Jim, while I personally don't care much, Zope3's repackaging of docutils doesn't meet license requirements to retain the original licenses in derivative works. Zope2's does, because it includes docutil's whole 'licenses' subdirectory (except for the GPL).
At least as of the time that I added docutils to Zope 3, it had no licenses. Nevertheless, I include a mention of the docutils non-license in: http://svn.zope.org/Zope3/trunk/LICENSES.txt?view=markup Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
[Tim Peters]
Jim, while I personally don't care much, Zope3's repackaging of docutils doesn't meet license requirements to retain the original licenses in derivative works. Zope2's does, because it includes docutil's whole 'licenses' subdirectory (except for the GPL).
[Jim Fulton]
At least as of the time that I added docutils to Zope 3, it had no licenses. Nevertheless, I include a mention of the docutils non-license in:
The current docutils package includes 4 licenses. You mention roman.py in the above, and docutils is in part a derivative of that, so Zope3 is too, and the Python 2.1.1 license roman.py was released under requires retaining the license in derivative works. Including a link to the license doesn't meet that requirement, although I strongly doubt roman.py's author would object. It's exciting to live dangerously <wink>.
--On Montag, 20. Dezember 2004 11:08 Uhr -0500 Tim Peters <tim.peters@gmail.com> wrote:
[Jim Fulton]
We include all of docutils in Zope 3 and don't adjust the paths. We *did*adjust docutils slightly.
[Andreas Jung]
No, Zope 3 ships only with the 'docutils' subdirectory of the Docutils package.
[Jim]
What is it lacking?
I suppose it's the 'docs', 'extras', 'licenses' and 'tools' subdirectories, although I see that the 'tools' subdirectory checked in on Zope-2_7-branch was stripped of its GPL'ed pieces first.
Andreas, does Zope 2 *use* any of the stuff in the non-docutils subdirectories?
Jim, while I personally don't care much, Zope3's repackaging of docutils doesn't meet license requirements to retain the original licenses in derivative works. Zope2's does, because it includes docutil's whole 'licenses' subdirectory (except for the GPL).
I think we should stop the discussion at this point and follow Tres suggestion: - import Docutils somewhere into the CVS/SVN - link the docutils/docutils subfolder to lib/python in the CVS - move roman.py into parsers/rest as Jim did for Zope 3 I have no idea how we should with this issue in the SVN. Maybe svn:externals will do the job either to the Docutils version within Z3 or a shared Docutils shared somewhere within the SVN. Andreas
Andreas Jung wrote:
--On Montag, 20. Dezember 2004 11:08 Uhr -0500 Tim Peters <tim.peters@gmail.com> wrote:
[Jim Fulton]
We include all of docutils in Zope 3 and don't adjust the paths. We *did*adjust docutils slightly.
[Andreas Jung]
No, Zope 3 ships only with the 'docutils' subdirectory of the Docutils package.
[Jim]
What is it lacking?
I suppose it's the 'docs', 'extras', 'licenses' and 'tools' subdirectories, although I see that the 'tools' subdirectory checked in on Zope-2_7-branch was stripped of its GPL'ed pieces first.
Andreas, does Zope 2 *use* any of the stuff in the non-docutils subdirectories?
Jim, while I personally don't care much, Zope3's repackaging of docutils doesn't meet license requirements to retain the original licenses in derivative works. Zope2's does, because it includes docutil's whole 'licenses' subdirectory (except for the GPL).
I think we should stop the discussion at this point
Well, we do need to decide how to handle the license files. I suggest we create a licenses dir in the doctest package. (In Zope 3, I include ICU's license file with the icu data files.
and follow Tres suggestion:
- import Docutils somewhere into the CVS/SVN
- link the docutils/docutils subfolder to lib/python in the CVS
- move roman.py into parsers/rest as Jim did for Zope 3
I have no idea how we should with this issue in the SVN. Maybe svn:externals will do the job either to the Docutils version within Z3 or a shared Docutils shared somewhere within the SVN.
I prefer to use svn cp. For now, just svn cp the docutils directory from the zope 3 tree. Later (or now, if you want to bother), we should create a vendor-import area in the repository and create a vendor import for docutils. Then copy from there. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
participants (7)
-
Andreas Jung -
Christian Theune -
Dieter Maurer -
Jim Fulton -
Stefan H. Holek -
Tim Peters -
Tres Seaver