On 1 April 2010 23:59, Eric Abrahamsen <[email protected]> wrote: > 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...
Any progress on getting a small self contained example together which shows the problem? Graham >> >> 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. > > -- 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.
