[04:03:00] [connected at Thu Apr 20 04:03:00 2006] [04:03:00] <> *** Looking up your hostname... [04:03:00] <> *** Checking ident [04:03:00] <> *** Found your hostname [04:03:31] <> *** No identd (auth) response [04:03:31] <> *** Your host is niven.freenode.net[niven.freenode.net/6667], running version hyperion-1.0.2 [04:03:31] [I have joined #peak] [08:07:42] [Global Notice] Hi all. We'll be restarting services in just a moment. There will be a brief delay, and we hope to have upgraded services online pretty quickly. Thanks. [10:03:37] ** DesreveR has left IRC (Read error: 104 (Connection reset by peer)) [10:05:23] ** r0nny has joined us [10:35:23] ** r0nny has left IRC ("hard-disk-failure") [12:00:53] ** pje has joined us [13:07:50] hey pje, everytime I install something with easy_install & setuptools .6a11, I get the following line in my easy-install.pth [13:07:53] import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert = p+len(new) [13:08:06] this kill Zope2 on start up [13:08:15] how does it kill Zope? [13:08:15] is there something I can do about this? [13:08:42] looks like the import path Zope 2 tries to setup disappear [13:09:05] Hm. I'd think that this would run *before* Zope ever gets imported [13:09:19] .pth files are processed during Python startup, before running a script [13:09:34] So I'm surprised, unless Zope is calling 'site.addsitedir()' [13:09:35] Is it? [13:09:55] maybe...this is the zopectl script that is having a problem [13:10:18] Could you check? [13:10:20] * whit takes a look [13:10:55] but that line is there to do something meaningful? I've been fixing the problem by removing it [13:16:04] Zope2.9/lib/python/site calls addsitedir [13:16:12] let me paste that code [13:16:40] http://paste.plone.org/3438 [13:38:21] er, you pasted the site.py [13:39:05] That code is what's installed by easy_install [13:39:18] what's the script that's *having* the problem? [13:39:57] ok...that was in Zope2.9/lib/python [13:40:34] is that the problem maybe? [13:41:13] I didn't find any calls to addsitedir elsewhere in the zope code [13:43:06] It would really help if you'd tell me what, specifically, is breaking, how. [13:43:14] 'cause right now all I know is "there's a problem" :) [13:43:53] For example, is something importing the wrong version of something? [13:43:59] Is something not found that should be? [13:44:03] etc. [13:44:16] the latter actually [13:44:34] basically the symptom manifest like this [13:44:43] I install something with easy_install [13:44:59] the line above is added to my easy_install.pth [13:45:11] I try to restart zope [13:45:33] I get an import error for AccessControl.ImplPython [13:45:59] as a relative import not found [13:46:09] the file is in the proper place [13:46:29] I remove line from easy_install.pth...everything is fine [13:46:56] AccessControl is a top-level zope Package [13:48:23] not sure if that helps....is there some other kind of path modification info I can grep for [13:49:36] here the the tb: http://paste.plone.org/3439 [13:49:49] pje is now known as pje_mtg [13:51:09] could you print one sys.path value with the .pth, and one without? [13:51:18] so we can see what's different between them? [13:51:34] also, are there any other import lines in the .pth file, besides one at the top and one at the bottom? [13:51:59] import line other than eggs? [13:53:46] lines starting with "import" [13:56:19] * whit nods [13:56:33] here the path before easy_install: http://paste.plone.org/3440 [13:57:50] just the imports at the top and bottom [13:58:51] wow, that's pretty long [13:59:06] can you do a "diff" for the "after" path? [13:59:34] let me get you a diff [13:59:39] comin up [14:03:13] this sort of sucks to look at... http://paste.plone.org/3441 [14:04:23] scanning it, I don't see anything that would directly effect zope's import paths [14:04:56] what does that last import line do? [14:06:33] It pushes the added paths to the *beginning* of sys.path [14:07:56] Could you also do a diff of a sorted version? My guess is that this is exactly the same list of paths. [14:08:11] I'm not clear on why something's not being found, if it's only an order change [14:09:13] I see what you mean [14:11:17] pje_mtg is now known as pje [14:12:14] The only possibility that I see is if there is a package in one of the moved path items that is blocking something [14:12:25] because it's a package, but it's missing the thing being imported [14:12:35] i.e., only for top-level imports is order irrelevant [14:12:46] is the imported thing under zope.* [14:12:48] ? [14:16:05] syspaths are the same [14:17:06] it shouldn't be...the module missing is part of Zope2, not zope [14:17:39] ie zope3 stuff [14:18:37] currently, the only zope specific thing is zope.interface [14:18:47] in the pth [14:18:56] I'll remove it and see if that helps [14:20:04] that seems to do it....thank you pje [14:20:37] removing zope.interface fixes it? [14:20:45] yeah [14:20:59] probably zope isn't a namespace package. [14:21:18] but the thing that goes missing is under zope. package? [14:21:25] or is it under Zope? [14:21:28] (capital Z) [14:21:43] Oh hell, I bet that's it, isn't it? Mac OS is case insensitive... [14:23:35] ugh.....damn hfs [14:23:45] that honks [14:24:29] Well, Python should be checking that, actually. [14:24:44] On Windows, if it sees Zope and you imported 'zope', it's an error. [14:25:01] It should be doing that check on OS X too [14:25:10] you might want to file a bug for that [14:27:20] * whit nods [14:28:03] * whit tries a quick test [15:03:16] pje is now known as pje_afk [15:52:19] pje_afk is now known as pje [23:16:45] ** pje has left IRC ("Client exiting")