[Zope-dev] Why third_party/docutils?

2004-11-29 Thread 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)? Extending the path in lib/python/sitecustomize only works if

Re: [Zope-dev] Why third_party/docutils?

2004-11-29 Thread Andreas Jung
--On Montag, 29. November 2004 12:43 Uhr +0100 Stefan H. Holek [EMAIL PROTECTED] 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

[Zope-dev] CatalogBrains.getObject and unrestricted code

2004-11-29 Thread Florent Guillaume
In ZCatalog's brains, getObject currently does a restrictedTraverse to get the object. That's a problem for unrestricted code that needs to get to the object nevertheless, even if the user cannot get to it. For instance CMF is impacted, when it tries to reindex the security of all subobjects

Re: [Zope-dev] CatalogBrains.getObject and unrestricted code

2004-11-29 Thread Andreas Jung
--On Montag, 29. November 2004 18:15 Uhr +0100 Florent Guillaume [EMAIL PROTECTED] wrote: In ZCatalog's brains, getObject currently does a restrictedTraverse to get the object. That's a problem for unrestricted code that needs to get to the object nevertheless, even if the user cannot get to

Re: [Zope-dev] CatalogBrains.getObject and unrestricted code

2004-11-29 Thread Florent Guillaume
Yes, http://collector.zope.org/Zope/1534 is related. But in any case if getObject returns a subset of available objects (and None or Unauthorized for the others), we still needs a _getObject method that returns all of them, for unrestricted code. Florent Andreas Jung wrote: --On Montag, 29.

Re: [Zope-dev] Why third_party/docutils?

2004-11-29 Thread Dieter Maurer
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

[Zope-dev] Re: Why third_party/docutils?

2004-11-29 Thread Tres Seaver
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

Re: [Zope-dev] Why third_party/docutils?

2004-11-29 Thread Jim Fulton
Andreas Jung wrote: --On Montag, 29. November 2004 12:43 Uhr +0100 Stefan H. Holek [EMAIL PROTECTED] 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-dev] including docutils in Zope -- two issues: IP and location

2004-11-29 Thread Jim Fulton
I can understand the desire to include docutils in Zope. We made this decision for Zope 3 a while ago. Such a decision needs to be made *very* carefully for intellectual property reasons. Contributors other than Zope Corporation employees can only check in *their* code. This is important to

[Zope-dev] Re: CatalogBrains.getObject and unrestricted code

2004-11-29 Thread Casey Duncan
In article [EMAIL PROTECTED], Florent Guillaume [EMAIL PROTECTED] wrote: In ZCatalog's brains, getObject currently does a restrictedTraverse to get the object. That's a problem for unrestricted code that needs to get to the object nevertheless, even if the user cannot get to it. For