[Zope-dev] Why third_party/docutils?
[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/ ___ 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 )
Re: [Zope-dev] Why third_party/docutils?
--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 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 ___ 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] CatalogBrains.getObject and unrestricted code
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 of a given object. Unless someone is opposed to it, I'll add a _getObject method that does an unrestrictedTraverse, and make CMF use it if available. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 )
Re: [Zope-dev] CatalogBrains.getObject and unrestricted code
--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 it. For instance CMF is impacted, when it tries to reindex the security of all subobjects of a given object. Unless someone is opposed to it, I'll add a _getObject method that does an unrestrictedTraverse, and make CMF use it if available. There is already a collector issue #1534 where ChrisW tracked something down in Traversable.py. However I have no idea if this is true or related to the problem. Andreas ___ 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 )
Re: [Zope-dev] CatalogBrains.getObject and unrestricted code
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. 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 it. For instance CMF is impacted, when it tries to reindex the security of all subobjects of a given object. Unless someone is opposed to it, I'll add a _getObject method that does an unrestrictedTraverse, and make CMF use it if available. There is already a collector issue #1534 where ChrisW tracked something down in Traversable.py. However I have no idea if this is true or related to the problem. Andreas -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 )
Re: [Zope-dev] Why third_party/docutils?
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 ___ 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 )
Re: [Zope-dev] Why third_party/docutils?
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 (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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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] including docutils in Zope -- two issues: IP and location
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 reduce the risk of an IP problem. This means, unfortunatelky, that third-party code puts a burden on Zope Corporation, and thus, the community, since we become a bottle neck. Whatever we do with distutils, we have to make sure that Zope Corporation is involved and that ZC employees check in any code changes. (I assume that Andreas was a ZC employee when this code was originally checked in.) WRT location, I'd like to keep things as simple as possible. Top-level packages in the Zope 2 tree should be in lib/python. This is what was done for Zope 3 and it has worked well. Andreas, I'd be happy to sort this out with you off line if you like. Perhaps we can do with Zope 2 what we did for Zope 3, and, for Zope 2.8, perhaps we can even share the same tree. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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: CatalogBrains.getObject and unrestricted code
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 instance CMF is impacted, when it tries to reindex the security of all subobjects of a given object. Unless someone is opposed to it, I'll add a _getObject method that does an unrestrictedTraverse, and make CMF use it if available. Florent getObject must be restricted since it can be called by untrusted code. It has been argued that it is currently too restrictive, and it should only validate the leaf object, but nothing has been done about this AFAIK. You can work around this issue by using:: unrestrictedTraverse(brain.getPath()) A (restricted) convenience method to do this could be added, but it doesn't really seem worth the effort IMO. -Casey ___ 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 )
