-
Holy Twilight Zone! (AKA: It was ALL working 5 days ago)
from dennisharrison on Jul 29, 2008 02:21 PMI had recently made a checkout of my development buildout on a local dev server to create a new site. virtualenv it up, run the buildout, get new version of membrane to handle those security issues in the gs that david bain brought up. And everything from that point on was roses. Do further development. Write a bunch of extensions to getpaid to handle paypal ipn and taxes, tax lookup, etc... and then merge the changes to a staging buildout, I just install all the products looking for an obvious error in fg, don't see any and we move on to checking all that in to production. So I get everything back up on production and lo-and-behold! I can't get to remember. Now, the confusing part comes in here ... I go back to my local checkout of dev (5 days ago) and everything works. I make sure svn is the same. It is. So I checkout another copy of the dev buildout, and I can't make the new checkout work either. I feel like I am going crazy :) However, I found someone else with the same problem... and he has a resolution. But I just don't know that I should have to worry about this, as everything 'was' working and that was with plone 3.1.3 / membrane 1.1b4 / remember 1.1svn http://sharbas.blogspot.com/2008/03/membraneremember-in-plone3.html Did anything funky happen recently I might not be aware of? Did I sleep through fixing this problem once already. Am I checking out the wrong versions? help? -- Dennis J Harrison Jr Solutions Architect - Absolute IT RHCE, CCNE, CEH dennis@... B: 504.754.1343 C: 985.590.0420
- Thread Outline:
-
Re: Holy Twilight Zone! (AKA: It was ALL working 5 days ago)
from dennisharrison on Jul 29, 2008 02:42 PMActually, looking over that other traceback. The error is not the same. Here is the traceback I am seeing. http://paste.plone.org/22858 This is on a brand new checkout with Products.remember Products.membrane from trunk in as dev eggs. This site has nothing but membrane / remember installed. On Tue, Jul 29, 2008 at 1:21 PM, Dennis J Harrison Jr < dennis@...> wrote: > I had recently made a checkout of my development buildout on a local dev > server to create a new site. > > virtualenv it up, run the buildout, get new version of membrane to handle > those security issues in the gs that david bain brought up. And everything > from that point on was roses. Do further development. Write a bunch of > extensions to getpaid to handle paypal ipn and taxes, tax lookup, etc... and > then merge the changes to a staging buildout, I just install all the > products looking for an obvious error in fg, don't see any and we move on to > checking all that in to production. So I get everything back up on > production and lo-and-behold! I can't get to remember. > > Now, the confusing part comes in here ... I go back to my local checkout of > dev (5 days ago) and everything works. I make sure svn is the same. It > is. So I checkout another copy of the dev buildout, and I can't make the > new checkout work either. I feel like I am going crazy :) > > However, I found someone else with the same problem... and he has a > resolution. But I just don't know that I should have to worry about this, > as everything 'was' working and that was with plone 3.1.3 / membrane 1.1b4 / > remember 1.1svn > > http://sharbas.blogspot.com/2008/03/membraneremember-in-plone3.html > > Did anything funky happen recently I might not be aware of? Did I sleep > through fixing this problem once already. Am I checking out the wrong > versions? > > help? > > -- > Dennis J Harrison Jr > Solutions Architect - Absolute IT > RHCE, CCNE, CEH > dennis@... > B: 504.754.1343 > C: 985.590.0420 > -- Dennis J Harrison Jr Solutions Architect - Absolute IT RHCE, CCNE, CEH dennis@... B: 504.754.1343 C: 985.590.0420
-
Dennis J Harrison Jr wrote: > Actually, looking over that other traceback. The error is not the > same. Here is the traceback I am seeing. > > http://paste.plone.org/22858 > > This is on a brand new checkout with Products.remember Products.membrane > from trunk in as dev eggs. This site has nothing but membrane / > remember installed. i've done a bit of research... is it possible that you have a dependency problem, where you have a newer version of zope.interface installed in your environment, which is overriding the zope.interface implementation that would be the default in your Plone build? the ArchetypeTool has a 'listPortalTypesWithInterfaces' method, which accepts a sequence of interfaces and calls 'iface.isImplementedByInstancesOf(klass)' on each one, for each type. the 'isImplementedByInstancesOf' method is deprecated; the preferred spelling would be 'iface.implementedBy(klass)'. this deprecated method was removed from zope.interface in r70211: http://svn.zope.org/Zope3/trunk/src/zope/interface/interface.py?rev=70211&r1=70082&r2=70211 it seems that you've somehow ended up w/ an implementation of zope.interface that is newer than r70211. it seems unlikely to me that Plone is shipping with a version of zope.interface that is newer than this... if it is, then this should be considered an Archetypes bug, b/c AT clearly shouldn't be calling methods that are no longer available. more likely is that some other package that you have installed declared zope.interface as a dependency, and a more recent version of zope.interface was installed which is now conflicting w/ the one that your Plone version installed. it's possible that this has happened at the system level. when you created your virtualenv, did you use the --no-site-packages option? -r > On Tue, Jul 29, 2008 at 1:21 PM, Dennis J Harrison Jr > <dennis@... <mailto:dennis@...>> wrote: > > I had recently made a checkout of my development buildout on a local > dev server to create a new site. > > virtualenv it up, run the buildout, get new version of membrane to > handle those security issues in the gs that david bain brought up. > And everything from that point on was roses. Do further > development. Write a bunch of extensions to getpaid to handle > paypal ipn and taxes, tax lookup, etc... and then merge the changes > to a staging buildout, I just install all the products looking for > an obvious error in fg, don't see any and we move on to checking all > that in to production. So I get everything back up on production > and lo-and-behold! I can't get to remember. > > Now, the confusing part comes in here ... I go back to my local > checkout of dev (5 days ago) and everything works. I make sure svn > is the same. It is. So I checkout another copy of the dev > buildout, and I can't make the new checkout work either. I feel > like I am going crazy :) > > However, I found someone else with the same problem... and he has a > resolution. But I just don't know that I should have to worry about > this, as everything 'was' working and that was with plone 3.1.3 / > membrane 1.1b4 / remember 1.1svn > > http://sharbas.blogspot.com/2008/03/membraneremember-in-plone3.html > > Did anything funky happen recently I might not be aware of? Did I > sleep through fixing this problem once already. Am I checking out > the wrong versions? > > help? > > -- > Dennis J Harrison Jr > Solutions Architect - Absolute IT > RHCE, CCNE, CEH > dennis@... <mailto:dennis@...> > B: 504.754.1343 > C: 985.590.0420
-
Re: Re: Holy Twilight Zone! (AKA: It was ALL working 5 days ago)
from "Justin Ryan"on Jul 29, 2008 08:14 PM On Tue, Jul 29, 2008 at 12:40 PM, Rob Miller <robm@...> wrote: > > i've done a bit of research... is it possible that you have a dependency > problem, where you have a newer version of zope.interface installed in your > environment, which is overriding the zope.interface implementation that > would be the default in your Plone build? > Thanks, Rob, I was thinking in this direction but assumed we had an older package in the live setup which still fulfilled a dependency of something. > the ArchetypeTool has a 'listPortalTypesWithInterfaces' method, which > accepts a sequence of interfaces and calls > 'iface.isImplementedByInstancesOf(klass)' on each one, for each type. the > 'isImplementedByInstancesOf' method is deprecated; the preferred spelling > would be 'iface.implementedBy(klass)'. > > this deprecated method was removed from zope.interface in r70211: > > http://svn.zope.org/Zope3/trunk/src/zope/interface/interface.py?rev=70211&r1=70082&r2=70211 > > it seems that you've somehow ended up w/ an implementation of zope.interface > that is newer than r70211. it seems unlikely to me that Plone is shipping > with a version of zope.interface that is newer than this... if it is, then > this should be considered an Archetypes bug, b/c AT clearly shouldn't be > calling methods that are no longer available. > It seems that, today, we've already spent enough time on it to justify considering it a bug, because that method has been deprecated for ages, IIRC. It is probably prime time to change that, though, as far as I can tell, Plone is not giving us this version of zope.interface, I may have installed an egg at system level for something that uses mod_python, which I should probably try and figure a way to use virtualenv for. > more likely is that some other package that you have installed declared > zope.interface as a dependency, and a more recent version of zope.interface > was installed which is now conflicting w/ the one that your Plone version > installed. it's possible that this has happened at the system level. when > you created your virtualenv, did you use the --no-site-packages option? > Yeah, no, heh. We probably should consider that option, or at least be a lot more careful with system-level site packages. The challenge is, now that we have System Python 2.4 in RHEL5, and it has RPMs for things like PIL and libxml2, it's convenient to use those instead of reinstalling them into virtualenv, esp as they are not eggs and seem actually to menially respect the virtualenv. Thanks, again.. J -- Justin Alan Ryan Independent Interaction Architect http://www.bitmonk.net/ * : +1-415-226-1199 x2600 "All because of a bunch of stuff that happened.." -Homer Simpson
-
Justin Ryan wrote: > On Tue, Jul 29, 2008 at 12:40 PM, Rob Miller <robm@...> wrote: >> more likely is that some other package that you have installed declared >> zope.interface as a dependency, and a more recent version of zope.interface >> was installed which is now conflicting w/ the one that your Plone version >> installed. it's possible that this has happened at the system level. when >> you created your virtualenv, did you use the --no-site-packages option? >> > > Yeah, no, heh. We probably should consider that option, or at least > be a lot more careful with system-level site packages. > > The challenge is, now that we have System Python 2.4 in RHEL5, and it > has RPMs for things like PIL and libxml2, it's convenient to use those > instead of reinstalling them into virtualenv, esp as they are not eggs > and seem actually to menially respect the virtualenv. PIL has been packaged up as an egg by the repoze guys, at dist.repoze.org; i've been using this for a bit and have been happy w/ it. i'm not sure if there are any usable lxml2 eggs, but there are buildouts for it, so if you're using buildout (IIRC you said you were) you can probably wire it in that way. -r
-
Re: Re: Holy Twilight Zone! (AKA: It was ALL working 5 days ago)
from dennisharrison on Jul 29, 2008 11:53 PMzope.interface-3.4.1-py2.4-linux-i686.egg Was the offender. Going to do some more checkup and see what actually put that in there though. Will update this when we nail it down. Thanks a ton Rob! On Tue, Jul 29, 2008 at 7:21 PM, Rob Miller <robm@...> wrote: > Justin Ryan wrote: > >> On Tue, Jul 29, 2008 at 12:40 PM, Rob Miller <robm@...> wrote: >> >>> more likely is that some other package that you have installed declared >>> zope.interface as a dependency, and a more recent version of >>> zope.interface >>> was installed which is now conflicting w/ the one that your Plone version >>> installed. it's possible that this has happened at the system level. >>> when >>> you created your virtualenv, did you use the --no-site-packages option? >>> >>> >> Yeah, no, heh. We probably should consider that option, or at least >> be a lot more careful with system-level site packages. >> >> The challenge is, now that we have System Python 2.4 in RHEL5, and it >> has RPMs for things like PIL and libxml2, it's convenient to use those >> instead of reinstalling them into virtualenv, esp as they are not eggs >> and seem actually to menially respect the virtualenv. >> > > PIL has been packaged up as an egg by the repoze guys, at dist.repoze.org; > i've been using this for a bit and have been happy w/ it. > > i'm not sure if there are any usable lxml2 eggs, but there are buildouts > for it, so if you're using buildout (IIRC you said you were) you can > probably wire it in that way. > > -r > > > -- > Archive: > http://www.openplans.org/projects/remember/lists/remember/archive/2008/07/1217377308443 > > To unsubscribe send an email with subject "unsubscribe" to > remember@.... Please contact > remember-manager@... for questions. > > -- Dennis J Harrison Jr Solutions Architect - Absolute IT RHCE, CCNE, CEH dennis@... B: 504.754.1343 C: 985.590.0420
-
Re: Re: Holy Twilight Zone! (AKA: It was ALL working 5 days ago)
from dennisharrison on Jul 30, 2008 12:58 AMAlrighty, haven't had time to figure that out yet. This is the next error in line. Going to see if I just dump all the eggs over from the other buildout if it will work. In the meantime thought I would post this traceback here in case someone has seen this before. TypeError: unsubscriptable object http://paste.plone.org/22862 On Tue, Jul 29, 2008 at 10:53 PM, Dennis J Harrison Jr < dennis@...> wrote: > zope.interface-3.4.1-py2.4-linux-i686.egg > > Was the offender. Going to do some more checkup and see what actually put > that in there though. Will update this when we nail it down. > > Thanks a ton Rob! > > > > > On Tue, Jul 29, 2008 at 7:21 PM, Rob Miller <robm@...> wrote: > >> Justin Ryan wrote: >> >>> On Tue, Jul 29, 2008 at 12:40 PM, Rob Miller <robm@...> wrote: >>> >>>> more likely is that some other package that you have installed declared >>>> zope.interface as a dependency, and a more recent version of >>>> zope.interface >>>> was installed which is now conflicting w/ the one that your Plone >>>> version >>>> installed. it's possible that this has happened at the system level. >>>> when >>>> you created your virtualenv, did you use the --no-site-packages option? >>>> >>>> >>> Yeah, no, heh. We probably should consider that option, or at least >>> be a lot more careful with system-level site packages. >>> >>> The challenge is, now that we have System Python 2.4 in RHEL5, and it >>> has RPMs for things like PIL and libxml2, it's convenient to use those >>> instead of reinstalling them into virtualenv, esp as they are not eggs >>> and seem actually to menially respect the virtualenv. >>> >> >> PIL has been packaged up as an egg by the repoze guys, at dist.repoze.org; >> i've been using this for a bit and have been happy w/ it. >> >> i'm not sure if there are any usable lxml2 eggs, but there are buildouts >> for it, so if you're using buildout (IIRC you said you were) you can >> probably wire it in that way. >> >> -r >> >> >> -- >> Archive: >> http://www.openplans.org/projects/remember/lists/remember/archive/2008/07/1217377308443 >> >> To unsubscribe send an email with subject "unsubscribe" to >> remember@.... Please contact >> remember-manager@... for questions. >> >> > > > -- > Dennis J Harrison Jr > Solutions Architect - Absolute IT > RHCE, CCNE, CEH > dennis@... > B: 504.754.1343 > C: 985.590.0420 > -- Dennis J Harrison Jr Solutions Architect - Absolute IT RHCE, CCNE, CEH dennis@... B: 504.754.1343 C: 985.590.0420
-
-
-
-
-
text.html (text/html) 1.8 kB
text.html (text/html) 2.8 kB