On Wed, 2010-03-31 at 21:38 +1100, Graham Dumpleton wrote: > Do you reckon there is any chance of you coming up with the absolute > minimum example of a Django site which exhibits the problem that you > could tar up and send me to play with? Guessing it would just need the > tag library definition and templates. I don't know that much about > using Django though, so may not be that simple.
Gah, the simplest possible setup of course creates no error. At least, it doesn't using apache/modwsgi on my local setup rather than my webhost, using sqlite3 instead of mysql... there are just a million variables which could be affecting this. I'll slowly build this up until it bombs, then send it to you... E > > Graham > > On 30 March 2010 23:33, Eric Abrahamsen <[email protected]> wrote: > > On Tue, 2010-03-30 at 22:06 +1100, Graham Dumpleton wrote: > >> On 30 March 2010 13:44, Eric Abrahamsen <[email protected]> wrote: > >> > On Tue, 2010-03-30 at 13:22 +1100, Graham Dumpleton wrote: > >> >> On 30 March 2010 12:35, Eric Abrahamsen <[email protected]> wrote: > >> >> > On Tue, 2010-03-30 at 08:57 +1100, Graham Dumpleton wrote: > >> >> >> On 29 March 2010 22:23, Eric <[email protected]> wrote: > >> >> >> > Hi, I am 锁柱子 from the "improved wsgi script" blog post, thanks very > >> >> >> > much Graeme for taking the time to look at this issue. I tried your > >> >> >> > suggestions from the simplest first, running: > >> >> >> > > >> >> >> > python manage.py shell > >> >> >> > import comments > >> >> >> > comments.__file__ > >> >> >> > > >> >> >> > produced the right results both with and without the "mysite" > >> >> >> > prepended to the import path. > >> >> >> > > >> >> >> > Then I added os.chdir('path/to/mysite') at the top of the wsgi > >> >> >> > script, > >> >> >> > before anything else, but that didn't fix the problem. > >> >> >> > > >> >> >> > So I logged the calls to globals(), locals(), sys.modules.keys() > >> >> >> > and > >> >> >> > sys.modules['comments'].__file__ as you indicated, inside the > >> >> >> > templatetags library that's exploding. There's a heck of a lot of > >> >> >> > stuff in there so I won't paste everything unless necessary. > >> >> >> > Logging > >> >> >> > this in the "broken" setup (without "mysite" prepended to the > >> >> >> > import > >> >> >> > path), I noticed first of all that in both locals() and globals(), > >> >> >> > __file__ pointed to the correct file, but __name__ pointed to > >> >> >> > "django.templatetags.entry_tags". I don't know if django munges > >> >> >> > import > >> >> >> > paths to make it look like all templatetag libraries are housed > >> >> >> > under > >> >> >> > "django.templatetags", but this looked odd to me. > >> >> >> > > >> >> >> > Nothing else immediately stood out. In sys.modules.keys() there are > >> >> >> > the following comments-related entries, in the order they came out > >> >> >> > in > >> >> >> > the list: > >> >> >> > > >> >> >> > comments.forms > >> >> >> > django.contrib.comments.views.utils > >> >> >> > django.contrib.comments.views.django > >> >> >> > mysite.comments.forms > >> >> >> > django.contrib.comments.templatetags > >> >> >> > comments.admin > >> >> >> > django.contrib.comments > >> >> >> > django.contrib.comments.views.textwrap > >> >> >> > mysite.comments.comments > >> >> >> > django.contrib.comments.forms > >> >> >> > comments.common > >> >> >> > django.contrib.comments.views.comments > >> >> >> > django.contrib.comments.time > >> >> >> > django.contrib.comments.datetime > >> >> >> > comments.comments > >> >> >> > django.contrib.comments.admin > >> >> >> > django.contrib.comments.signals > >> >> >> > comments.pickle > >> >> >> > django.contrib.comments.views.moderation > >> >> >> > comments.django > >> >> >> > django.contrib.comments.feeds > >> >> >> > comments.datetime > >> >> >> > django.contrib.comments.models > >> >> >> > mysite.comments > >> >> >> > myapp.comments > >> >> >> > mysite.comments.django > >> >> >> > comments > >> >> >> > django.contrib.comments.managers > >> >> >> > django.contrib.comments.views > >> >> >> > django.contrib.comments.views.urllib > >> >> >> > comments.akismet > >> >> >> > django.contrib.comments.django > >> >> >> > comments.models > >> >> >> > > >> >> >> > The one "myapp" entry is the app that has the exploding > >> >> >> > templatetags > >> >> >> > library. > >> >> >> > > >> >> >> > I really have no idea if this is what I should be seeing or not... > >> >> >> > >> >> >> So I know where each is coming from, can you dump out: > >> >> >> > >> >> >> for name in sys.modules.keys(): > >> >> >> if 'comments' in name: > >> >> >> print name, sys.modules[name].__name__, > >> >> >> sys.modules[name].__file__ > >> >> >> > >> >> >> Also dump out: > >> >> >> > >> >> >> print sys.path > >> >> > > >> >> > Here goes: http://python.pastebin.com/i7UA2V33 > >> >> > > >> >> > Perhaps significantly, many of the module values were actually None. I > >> >> > had to check sys.modules[name] hasattr __name__/__file__ to avoid > >> >> > throwing AttributeErrors for a 'NoneType' object. That's what the "No > >> >> > name" and "No file" entries mean... > >> >> > >> >> That doesn't make a great deal of sense. My recollection is that > >> >> __name__ and __file__ should be set prior to global code in a module > >> >> being executed and thus even if you have import cycles such that > >> >> incompletely loaded modules are being imported, they at least should > >> >> be set. > >> >> > >> >> The only other thing I can think of that would cause this is if they > >> >> have implemented a lazy loading mechanism which replaces the module in > >> >> sys.modules with a class instance that wraps the original module. > >> >> These lazy loaders are a nuisance and can cause problems in > >> >> multithreaded applications. I have in the past been quite suspicious > >> >> of one lazy loader that does this in the Python standard library > >> >> itself. > >> >> > >> >> Can you enhance that script to dump out: > >> >> > >> >> str(type(sys.modules[name])) > >> > > >> > Unfortunately it's just what you'd expect: <type 'module'> for those > >> > entries with a valid __name__ and __file__, and <type 'NoneType'> for > >> > those without. > >> > > >> > I tried this on my development setup, just for the heck of it, and got > >> > the same results. > >> > >> Looking at django.contrib.comments, all the so called modules listed > >> in sys.modules which are supposed to be sub modules of that and which > >> show as type None, don't exist within the Django source code. > >> > >> The question thus is, why on earth are there entries in sys.modules > >> for them if they don't correspond to valid modules. That is truly > >> bizzare and have never seen anything like that before. > >> > >> Can you post the code you are currently using to generate the response > >> just so can ensure nothing obvious wrong being done? > > > > I get this error on any page that tries to load the "entry_tags" tag > > library. That includes the index page, and anywhere else where comment > > totals or comments themselves are loaded. There's nothing special about > > the entry_tags library, I've pasted (what I hope are) the relevant bits > > here: > > http://pastebin.com/L0YUBLh4 > > > > Could this be happening because of the depth of the templatetags > > directory in my app structure? Every other place where the "from > > comments.models" statement works is directly under my app directory, > > only this one is buried one more directory deep... > > > >> > >> Also, in your tag library where you have: > >> > >> from comments.models import MyComment > >> > >> does: > >> > >> from comments.models import BaseCommentAbstractModel > >> > >> work instead. > > > > This is very weird. The above code never worked (ie, it always had to be > > "from mysite.comments.models import MyComment"), but changing this to: > > "from mysite.comments.models import BaseCommentAbstractModel" and then > > changing the code that follows to match it works -- it pulls the > > appropriate comment data from the appropriate table. > > > > Still can't do: > > "from comments.models import BaseCommentAbstractModel", though, it > > returns the same error. > > > >> > >> I am wandering whether the context in which the tag library is > >> evaluated, whether it is picking up 'django.contrib.comments.models' > >> instead for some reason and thus your problems are because of bad > >> choice for your sub package in your application. > >> > >> If that second import works, then would possibly confirm that. > >> > >> What actually is in your 'comments.models'? > > > > The class is called MyComment and it inherits from > > BaseCommentAbstractModel. I wanted to just call it Comment, since that's > > what it was, but I also discovered that the names are overloaded and > > that caused problems, I think with the database tables, I can't > > remember. I wanted something pretty much just like the built in comments > > but with some extra fields -- I can't quite remember why now but it > > seemed like the only way to do that was to recreate the builtin > > comments, with my own changes. > > > > Then there are a couple of other models in there, allowing people to > > register for comment notifications, and a pile of signals. > > > >> > >> Can you rename 'comments' to 'xcomments' in your site and change all > >> the references and then see if it works without needing 'mysite' > >> prefix. > > > > I'm hoping something in the above solves the problem -- since this issue > > only appears on the production site I'd rather not muck with class and > > table names unless it's a last resort! > > > > Thanks as always, > > Eric > > > >> > >> In other words 'comments' is very heavily overloaded in its usage and > >> perhaps poor name to use for your own stuff. > >> > >> Graham > >> > >> Graham > >> > >> > Eric > >> > > >> >> > >> >> In other words, find out what the type of object is that is in > >> >> sys.modules. > >> >> > >> >> Graham > >> > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "modwsgi" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/modwsgi?hl=en. > > > > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
