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.
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.
