Fwd: [Zope] zopectl or runzope just won't start zope
Thanks for your reply fm. The python version in my path is 2.3.5 and both python and zope were build from source. Zope is installed in /opt which is where the python 2.3.5 is too. I got rid of the zope instance I had running earlier and created a new instance in my home directory. Now when I run zopectl start from the /bin in the instance in my home directory I get the following error: . Traceback (most recent call last): File "/opt/zope-2.8.4/lib/python/zdaemon/zdrun.py", line 719, in ? main() File "/opt/zope-2.8.4/lib/python/zdaemon/zdrun.py", line 716, in main d.main(args) File "/opt/zope-2.8.4/lib/python/zdaemon/zdrun.py", line 243, in main self.run() File "/opt/zope-2.8.4/lib/python/zdaemon/zdrun.py", line 256, in run self.opensocket() File "/opt/zope-2.8.4/lib/python/zdaemon/zdrun.py", line 278, in opensocket sock.bind(tempname) File "<string>", line 1, in bind socket.error: (2, 'No such file or directory') I then tried to run 'runzope' and got the following which don't look like errors: /home/blah/zope/Products/PortalTransforms/TransformEngine.py:18: DeprecationWarning: The module, 'Products.CMFCore.CMFCorePermissions' is a deprecated compatiblity alias for 'Products.CMFCore.permissions'; please use the new module instead. from Products.CMFCore import CMFCorePermissions /home/blah/zope/Products/CMFCore/utils.py:629: DeprecationWarning: format_stx() will be removed in CMF 1.6. Please use StructuredText.StructuredText.HTML instead. DeprecationWarning) /home/sra/zope/Products/kupu/__init__.py:23: DeprecationWarning: The Zope package has been renamed to Zope2. Import of a package named 'Zope' is deprecated and will be disabled starting in Zope 2.11. import Zope /home/blah/zope/Products/CMFFormController/__init__.py:25: DeprecationWarning: The product_name parameter of ToolInit is deprecated and will be ignored in CMF1.6: CMFFormController product_name='CMFFormController', icon='tool.gif', /home/blah/zope/Products/GroupUserFolder/__init__.py:99: DeprecationWarning: The product_name parameter of ToolInit is deprecated and will be ignored in CMF1.6: GroupUserFolder , icon="tool.gif" /home/sra/zope/Products/MimetypesRegistry/__init__.py:34: DeprecationWarning: The product_name parameter of ToolInit is deprecated and will be ignored in CMF1.6: MimetypesRegistry icon="tool.gif", /home/blah/zope/Products/PloneLanguageTool/__init__.py:17: DeprecationWarning: The product_name parameter of ToolInit is deprecated and will be ignored in CMF1.6: PloneLanguageTool icon='tool.gif', /home/sra/zope/Products/PortalTransforms/__init__.py:35: DeprecationWarning: The product_name parameter of ToolInit is deprecated and will be ignored in CMF1.6: PortalTransforms icon="tool.gif", /home/blah/zope/Products/ResourceRegistries/__init__.py:20: DeprecationWarning: The product_name parameter of ToolInit is deprecated and will be ignored in CMF1.6: ResourceRegistries icon = 'tool.gif', /home/blah/zope/Products/kupu/plone/__init__.py:31: DeprecationWarning: The product_name parameter of ToolInit is deprecated and will be ignored in CMF1.6: kupu icon="kupu_icon.gif", I finally made it to the ZMI, moved the folders from the untarred Plone tarball into the Products folder in the instance running in my home directory and restart the zope instance using runzope. I expect to see "Plone Site" in the drop down menu on the right but don't. I do a "Plone Language Tool". Could you help me figure out why "Plone Site" won't show up. Thank you very much for your time. Qass On 12/14/05, Floyd May <fmay@okcareertech.org> wrote:
First, I would recommend against changing anything in any file at this point except configuration files.
Next, verify that the correct python version is being used. It's easy to have two pythons side-by-side on the same linux system. If you built Zope from source, you (probably) should build python from source as well. However, if you used an installable package for Zope, I would recommend staying with whatever version pairing of Zope/Python that your Linux distribution has by default. It's simpler that way, and will probably solve your problem. I know that I've built Zope before where it's pointed at the wrong python version, and got things all screwed up for me. Use "`which python` -V" (those are backtics) to figure out the version that your $PATH points to by default.
If you *are* building from source, verify that you used --with-python="/path/to/python2.3.5" when you ran the configure script for Zope. The configure script should(?) tell you if there's a problem with any module dependencies. Again, if building Zope from source, it's probably best that you use a python built from source as well.
Good Luck! fm
On 12/14/05, Qass <qassair@gmail.com> wrote:
Hi:
I'm new to zope and yesterday installed zope 2.8.4 on a linux system running python 2.3.5 Having followed installation instructions I got to the point of 'zopectl start' and got the following error message while trying both 'runzope' and 'zopectl'.
I've tried installing different versions of Zope and get the same error (error absent with Zope 3). At one point, Zope did start (I moved it to a different port) but when I tried installing Plone in the Products directory of the zope instance, the 'Plone Site' did not show up in the drop down menu on the right hand side of the ZMI. Which is why I decided to reinstall and have been getting errors since. I haven't messed around with the Python installation at all.
In this latest install I ran 'make instance' intead of 'make install' just to see if I would get the same error as I did yesterday when I had an instance of Zope running and I did.
Any help in trying to fix this would be highly appreciated. I've tried changing PYTHONPATH in the zopectl file but that just leads to more and more errors.
Traceback (most recent call last): File
"/blah//Zope-2.8.4-final/lib/python/Zope2/Startup/run.py", line 56, in ?
run() File
"/blah/Zope-2.8.4-final/lib/python/Zope2/Startup/run.py", line 17, in run
import Zope2.Startup File "/blah/Zope-2.8.4-final/lib/python/Zope2/__init__.py", line 60, in
?
from Zope2.Startup.run import configure File
"/network/share/home/sra/Zope-2.8.4-final/lib/python/Zope2/Startup/__init__.py",
line 24, in ? import ZConfig File "/blah/Zope-2.8.4-final /lib/python/ZConfig/__init__.py", line 21, in ? from ZConfig.loader import loadConfig, loadConfigFile File "/blah/Zope-2.8.4-final/lib/python/ZConfig/loader.py", line 23, in ? import ZConfig.datatypes File "/blah/Zope-2.8.4-final/lib/python/ZConfig/datatypes.py", line 19, in ? import datetime File "/blah/Zope-2.8.4-final/lib/python/DateTime/__init__.py", line 13, in ? from DateTime import DateTime File "/blah/Zope-2.8.4-final/lib/python/DateTime/DateTime.py", line 21, in ? from datetime import datetime File "/blah/Zope-2.8.4-final/lib/python/DateTime/DateTime.py", line 21, in ? from datetime import datetime ImportError: cannot import name datetime
Thank you very much for your help.
Qass _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- Floyd May Senior Systems Analyst CTLN - CareerTech Learning Network fmay@okcareertech.org _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
I am trying to catch a 'BadRequest' exception in the following python script excerpt: for item in itemList: try: context.afolder.manage_delObjects([item]) except BadRequest: continue The rationale behind this is that itemList may contain entries that no longer exist in 'afolder', but I would like to delete whatever does exist. 'BadRequest' is not a python built-in exception, so whenever the above except clause is invoked it actually causes another error: Traceback (innermost last): Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module OFS.DTMLMethod, line 126, in __call__ Module DocumentTemplate.DT_String, line 474, in __call__ Module DocumentTemplate.DT_In, line 705, in renderwob Module DocumentTemplate.DT_Util, line 201, in eval - __traceback_info__: _ Module <string>, line 2, in f Module Shared.DC.Scripts.Bindings, line 252, in __call__ Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec Module Products.PythonScripts.PythonScript, line 315, in _exec Module Script (Python), line 25, in subDeleteAd - <PythonScript at /fas/subDeleteAd> - Line 25 NameError: global name 'BadRequest' is not defined I can work around this problem by checking to see if the item exists in 'afolder' before I try to delete it, but I was curious as to how you go about trapping a 'BadRequest' error in a python script? Thanks, Jonathan
Jonathan wrote:
I am trying to catch a 'BadRequest' exception in the following python script excerpt:
for item in itemList: try: context.afolder.manage_delObjects([item]) except BadRequest: continue
NameError: global name 'BadRequest' is not defined
The following would normally be required, but it fails with an ImportError: from zExceptions import BadRequest So you could try this instead: for item in itemList: try: context.afolder.manage_delObjects([item]) except: continue In general, TTW coding is very limited; you can use External Methods (a.k.a. Extensions) or Products to avoid this.
--On 14. Dezember 2005 12:54:56 -0700 Nikko Wolf <nikko-wolf@earthlink.net> wrote:
So you could try this instead:
for item in itemList: try: context.afolder.manage_delObjects([item]) except: continue
Wahhhh... DON'T DO THAT. You should *never* use bare try..excepts within Zope applications. This can lead to strange and unpredictable behavior. -aj
Thanks to everyone for the feedback... the bottom line seems to be that you can NOT trap zope exceptions in a python script... which seems a bit odd. Jonathan ----- Original Message ----- From: "Andreas Jung" <lists@andreas-jung.com> To: "Nikko Wolf" <nikko-wolf@earthlink.net>; <zope@zope.org> Sent: Wednesday, December 14, 2005 3:06 PM Subject: Re: [Zope] Trapping zope exceptions in python script
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Jonathan wrote:
Thanks to everyone for the feedback... the bottom line seems to be that you can NOT trap zope exceptions in a python script... which seems a bit odd.
Of course you can. You just are restricted from importing certain things, which happens to include this class of exception. Probably it is safe for Zope to allow importing this in restricted code; feel free to file a bug report. But you have easy avenues to deal with this: either declare that class safe for import or take a couple extra seconds and write it in an External Method. --jcc -- "Building Websites with Plone" http://plonebook.packtpub.com/ Enfold Systems, LLC http://www.enfoldsystems.com
----- Original Message ----- From: "J Cameron Cooper" <zope-l@jcameroncooper.com> To: "Jonathan" <dev101@magma.ca> Cc: <zope@zope.org> Sent: Wednesday, December 14, 2005 4:33 PM Subject: Re: [Zope] Trapping zope exceptions in python script
Jonathan wrote:
Thanks to everyone for the feedback... the bottom line seems to be that you can NOT trap zope exceptions in a python script... which seems a bit odd.
Of course you can. You just are restricted from importing certain things, which happens to include this class of exception. Probably it is safe for Zope to allow importing this in restricted code; feel free to file a bug report.
But you have easy avenues to deal with this: either declare that class safe for import or take a couple extra seconds and write it in an External Method.
Yes I know I can "force" python scripts to allow zExceptions, and yes I know that I can write an external method, but that was not the question. It seems strange that one can, using plain vanilla python scripts, trap bare 'try/excepts' (and I agree with Andreas that this is not a good thing to do!) and that one can trap python built-in exceptions, but that one cannot trap zope exceptions. Why allow python scripts to trap zope exceptions using a bare try/except (and then have to re-raise everything except the target zope exception), but not allow python scripts to target specific zope exceptions? I don't see the reasoning behind this approach. I don't think this is a bug, it is more of a feature request and does anybody else think it is reasonable/logical/useful? Just curious is all. Jonathan
--On 15. Dezember 2005 08:03:22 -0500 Jonathan <dev101@magma.ca> wrote:
----- Original Message ----- From: "J Cameron Cooper"
It seems strange that one can, using plain vanilla python scripts, trap bare 'try/excepts' (and I agree with Andreas that this is not a good thing to do!) and that one can trap python built-in exceptions, but that one cannot trap zope exceptions. Why allow python scripts to trap zope exceptions using a bare try/except (and then have to re-raise everything except the target zope exception), but not allow python scripts to target specific zope exceptions? I don't see the reasoning behind this approach.
My 2 cents: PythonScripts are restricted and are *not* thought to be a full replacement for Python modules. If you need this functionaltiy consider writing a Zope Product, using external methods or using TrustedExecutables. -aj
Andreas wrote:
My 2 cents: PythonScripts are restricted and are *not* thought to be a full replacement for Python modules. If you need this functionaltiy consider writing a Zope Product, using external methods or using TrustedExecutables.
If python scripts are restricted from accessing zExceptions (for security reasons???) then why allow python scripts to trap zExceptions in bare try/excepts? If the logic for not allowing zExceptions in plain vanilla python scripts is for security reasons, then allowing bare try/excepts would seem to be a security hole (though, I don't see the rationale for this). My 2 cents. Jonathan
Jonathan wrote:
Andreas wrote:
My 2 cents: PythonScripts are restricted and are *not* thought to be a full replacement for Python modules. If you need this functionaltiy consider writing a Zope Product, using external methods or using TrustedExecutables.
If python scripts are restricted from accessing zExceptions (for security reasons???) then why allow python scripts to trap zExceptions in bare try/excepts? If the logic for not allowing zExceptions in plain vanilla python scripts is for security reasons, then allowing bare try/excepts would seem to be a security hole (though, I don't see the rationale for this).
I would imagine that not allowing these exceptions to be imported in trusted code is simply an oversight. The mechanism involved is not a "you may not import this" type of thing, but rather a "you may import this" statement. It is easy to miss safe but rarely used pieces. If you have a list of exceptions you would like to have available, go and file a bug report. A patch would be even better. --jcc -- "Building Websites with Plone" http://plonebook.packtpub.com/ Enfold Systems, LLC http://www.enfoldsystems.com
Jonathan schrieb:
...
It seems strange that one can, using plain vanilla python scripts, trap bare 'try/excepts' (and I agree with Andreas that this is not a good thing to do!) and that one can trap python built-in exceptions, but that one cannot trap zope exceptions. Why allow python scripts to trap zope exceptions using a bare try/except (and then have to re-raise everything except the target zope exception), but not allow python scripts to target specific zope exceptions? I don't see the reasoning behind this approach.
Well you can trap any exception which happens between your try and except. But not outside of these, of course. This is true everywhere (not even python only ;) Which exceptions do you believe you might be not able to catch? HTH Tino
----- Original Message ----- From: "Tino Wildenhain" <tino@wildenhain.de> To: "Jonathan" <dev101@magma.ca> Cc: <zope@zope.org> Sent: Thursday, December 15, 2005 8:18 AM Subject: Re: [Zope] Trapping zope exceptions in python script
Jonathan schrieb:
...
It seems strange that one can, using plain vanilla python scripts, trap bare 'try/excepts' (and I agree with Andreas that this is not a good thing to do!) and that one can trap python built-in exceptions, but that one cannot trap zope exceptions. Why allow python scripts to trap zope exceptions using a bare try/except (and then have to re-raise everything except the target zope exception), but not allow python scripts to target specific zope exceptions? I don't see the reasoning behind this approach.
Well you can trap any exception which happens between your try and except. But not outside of these, of course. This is true everywhere (not even python only ;)
Which exceptions do you believe you might be not able to catch?
I encountered this situation while trying to trap 'BadRequest'. Jonathan
Am Mittwoch, den 14.12.2005, 16:20 -0500 schrieb Jonathan:
Thanks to everyone for the feedback... the bottom line seems to be that you can NOT trap zope exceptions in a python script... which seems a bit odd.
No, you can. But you should know what you do and reraise critical (e.g. Conflict exeptions and the like).
--On 14. Dezember 2005 16:20:57 -0500 Jonathan <dev101@magma.ca> wrote:
Thanks to everyone for the feedback... the bottom line seems to be that you can NOT trap zope exceptions in a python script... which seems a bit odd.
Nothing is odd. I just told you to avoid *bare* try..excepts..as Tino pointed out you should must reraise re-raise excepctions like ConflictErrors. Otherwise if you don#t know what you're doing, don't use bare try...excepts. -aj
Andreas Jung wrote:
--On 14. Dezember 2005 12:54:56 -0700 Nikko Wolf <nikko-wolf@earthlink.net> wrote:
So you could try this instead:
for item in itemList: try: context.afolder.manage_delObjects([item]) except: continue
Wahhhh... DON'T DO THAT. You should *never* use bare try..excepts within Zope applications. This can lead to strange and unpredictable behavior.
Can you elaborate on what "strange and unpredictable behavior" you mean? I'm curious in general, but especially w.r.t. the code above? BTW, a simple grep of sources in Zope (2.7.6-final) turns up 600+ places where a bare except is used, and my Zope instance (which uses Plone) contains over 350 more. Cheers, Nikko
On Dec 15, 2005, at 4:01 PM, Nikko Wolf wrote:
Can you elaborate on what "strange and unpredictable behavior" you mean? I'm curious in general, but especially w.r.t. the code above?
BTW, a simple grep of sources in Zope (2.7.6-final) turns up 600+ places where a bare except is used, and my Zope instance (which uses Plone) contains over 350 more.
Often when you see a bare except, it is after some of the specific important exceptions are caught and re-raised: try: something() except ConflictError: raise except: recover() Even this is pretty poor style anyway (If you don't know enough about what is going wrong to know what is being thrown, you probably shouldn't be in charge of recovering from it.) The problem with catching and swallowing ConflictError and similar internal Zope errors is that you leave your ZODB in an inconsistent state. Roughly, one request has started making modifications to the ZODB, then a second request has been making modifications to the same object. The ZODB has noticed this, and throws this ConflictError exception. It is expecting this exception to bubble up all the way out of your code, throwing away whatever potential modifications you have made to the ZODB and having Zope try your code again. (at that point, hopefully the task that didn't get the conflict error has completed and committed its changes. When your code is run again, it will see the new values from the other transaction. Here an (again very rough) example: Imagine that you have two collections of objects called "unprocessed" and "processed". A group of somethings or someones grab the next item in "unprocessed", and puts it into "processed". If two requests come in to grab the next item from "unprocessed" and put it one of the other buckets, at some point. one or both of them will get the ConflictError exception. If the exception is swallowed by the code both of them will save their copy of the object in "processed", and where you had one object before you now have two. If these objects were student quizzes, two copies of the same quiz will double the weight of the score. If these object were loan application, the amount of money you were paying out has doubled. All around bad news.
On 14 Dec 2005, at 19:54, Nikko Wolf wrote:
In general, TTW coding is very limited; you can use External Methods (a.k.a. Extensions) or Products to avoid this.
Please excuse my ignorance, but what does "TTW coding" mean exactly? Thanks JB ___________________________________________________________ Yahoo! Exclusive Xmas Game, help Santa with his celebrity party - http://santas-christmas-party.yahoo.net/
+-------[ Joe Bezier ]---------------------- | On 14 Dec 2005, at 19:54, Nikko Wolf wrote: | >In general, TTW coding is very limited; you can use External Methods | >(a.k.a. Extensions) or Products to avoid this. | > | Please excuse my ignorance, but what does "TTW coding" mean exactly? "Through The Web." -- Andrew Milton akm@theinternet.com.au
These sounds like Plone questions best asked on a Plone list... Chris Qass wrote:
Thanks for your reply fm.
The python version in my path is 2.3.5 and both python and zope were build from source. Zope is installed in /opt which is where the python 2.3.5 is too.
I got rid of the zope instance I had running earlier and created a new instance in my home directory.
Now when I run zopectl start from the /bin in the instance in my home directory I get the following error:
. Traceback (most recent call last): File "/opt/zope-2.8.4/lib/python/zdaemon/zdrun.py", line 719, in ? main() File "/opt/zope-2.8.4/lib/python/zdaemon/zdrun.py", line 716, in main d.main(args) File "/opt/zope-2.8.4/lib/python/zdaemon/zdrun.py", line 243, in main self.run() File "/opt/zope-2.8.4/lib/python/zdaemon/zdrun.py", line 256, in run self.opensocket() File "/opt/zope-2.8.4/lib/python/zdaemon/zdrun.py", line 278, in opensocket sock.bind(tempname) File "<string>", line 1, in bind socket.error: (2, 'No such file or directory')
I then tried to run 'runzope' and got the following which don't look like errors:
/home/blah/zope/Products/PortalTransforms/TransformEngine.py:18: DeprecationWarning: The module, 'Products.CMFCore.CMFCorePermissions' is a deprecated compatiblity alias for 'Products.CMFCore.permissions'; please use the new module instead. from Products.CMFCore import CMFCorePermissions /home/blah/zope/Products/CMFCore/utils.py:629: DeprecationWarning: format_stx() will be removed in CMF 1.6. Please use StructuredText.StructuredText.HTML instead. DeprecationWarning) /home/sra/zope/Products/kupu/__init__.py:23: DeprecationWarning: The Zope package has been renamed to Zope2. Import of a package named 'Zope' is deprecated and will be disabled starting in Zope 2.11. import Zope /home/blah/zope/Products/CMFFormController/__init__.py:25: DeprecationWarning: The product_name parameter of ToolInit is deprecated and will be ignored in CMF1.6: CMFFormController product_name='CMFFormController', icon='tool.gif', /home/blah/zope/Products/GroupUserFolder/__init__.py:99: DeprecationWarning: The product_name parameter of ToolInit is deprecated and will be ignored in CMF1.6: GroupUserFolder , icon="tool.gif" /home/sra/zope/Products/MimetypesRegistry/__init__.py:34: DeprecationWarning: The product_name parameter of ToolInit is deprecated and will be ignored in CMF1.6: MimetypesRegistry icon="tool.gif", /home/blah/zope/Products/PloneLanguageTool/__init__.py:17: DeprecationWarning: The product_name parameter of ToolInit is deprecated and will be ignored in CMF1.6: PloneLanguageTool icon='tool.gif', /home/sra/zope/Products/PortalTransforms/__init__.py:35: DeprecationWarning: The product_name parameter of ToolInit is deprecated and will be ignored in CMF1.6: PortalTransforms icon="tool.gif", /home/blah/zope/Products/ResourceRegistries/__init__.py:20: DeprecationWarning: The product_name parameter of ToolInit is deprecated and will be ignored in CMF1.6: ResourceRegistries icon = 'tool.gif', /home/blah/zope/Products/kupu/plone/__init__.py:31: DeprecationWarning: The product_name parameter of ToolInit is deprecated and will be ignored in CMF1.6: kupu icon="kupu_icon.gif",
I finally made it to the ZMI, moved the folders from the untarred Plone tarball into the Products folder in the instance running in my home directory and restart the zope instance using runzope. I expect to see "Plone Site" in the drop down menu on the right but don't. I do a "Plone Language Tool". Could you help me figure out why "Plone Site" won't show up.
Thank you very much for your time.
Qass
On 12/14/05, Floyd May <fmay@okcareertech.org> wrote:
First, I would recommend against changing anything in any file at this point except configuration files.
Next, verify that the correct python version is being used. It's easy to have two pythons side-by-side on the same linux system. If you built Zope from source, you (probably) should build python from source as well. However, if you used an installable package for Zope, I would recommend staying with whatever version pairing of Zope/Python that your Linux distribution has by default. It's simpler that way, and will probably solve your problem. I know that I've built Zope before where it's pointed at the wrong python version, and got things all screwed up for me. Use "`which python` -V" (those are backtics) to figure out the version that your $PATH points to by default.
If you *are* building from source, verify that you used --with-python="/path/to/python2.3.5" when you ran the configure script for Zope. The configure script should(?) tell you if there's a problem with any module dependencies. Again, if building Zope from source, it's probably best that you use a python built from source as well.
Good Luck! fm
On 12/14/05, Qass <qassair@gmail.com> wrote:
Hi:
I'm new to zope and yesterday installed zope 2.8.4 on a linux system running python 2.3.5 Having followed installation instructions I got to the point of 'zopectl start' and got the following error message while trying both 'runzope' and 'zopectl'.
I've tried installing different versions of Zope and get the same error (error absent with Zope 3). At one point, Zope did start (I moved it to a different port) but when I tried installing Plone in the Products directory of the zope instance, the 'Plone Site' did not show up in the drop down menu on the right hand side of the ZMI. Which is why I decided to reinstall and have been getting errors since. I haven't messed around with the Python installation at all.
In this latest install I ran 'make instance' intead of 'make install' just to see if I would get the same error as I did yesterday when I had an instance of Zope running and I did.
Any help in trying to fix this would be highly appreciated. I've tried changing PYTHONPATH in the zopectl file but that just leads to more and more errors.
Traceback (most recent call last): File
"/blah//Zope-2.8.4-final/lib/python/Zope2/Startup/run.py", line 56, in ?
run() File
"/blah/Zope-2.8.4-final/lib/python/Zope2/Startup/run.py", line 17, in run
import Zope2.Startup File "/blah/Zope-2.8.4-final/lib/python/Zope2/__init__.py", line 60, in
?
from Zope2.Startup.run import configure File
"/network/share/home/sra/Zope-2.8.4-final/lib/python/Zope2/Startup/__init__.py",
line 24, in ? import ZConfig File "/blah/Zope-2.8.4-final
/lib/python/ZConfig/__init__.py", line 21, in ?
from ZConfig.loader import loadConfig, loadConfigFile File "/blah/Zope-2.8.4-final/lib/python/ZConfig/loader.py", line 23, in
?
import ZConfig.datatypes File
"/blah/Zope-2.8.4-final/lib/python/ZConfig/datatypes.py", line 19, in ?
import datetime File
"/blah/Zope-2.8.4-final/lib/python/DateTime/__init__.py", line 13, in ?
from DateTime import DateTime File
"/blah/Zope-2.8.4-final/lib/python/DateTime/DateTime.py", line 21, in ?
from datetime import datetime File
"/blah/Zope-2.8.4-final/lib/python/DateTime/DateTime.py", line 21, in ?
from datetime import datetime ImportError: cannot import name datetime
Thank you very much for your help.
Qass _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- Floyd May Senior Systems Analyst CTLN - CareerTech Learning Network fmay@okcareertech.org _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (10)
-
Andreas Jung -
Andrew Langmead -
Andrew Milton -
Chris Withers -
J Cameron Cooper -
Joe Bezier -
Jonathan -
Nikko Wolf -
Qass -
Tino Wildenhain