#4659 closed Uncategorized (wontfix)
Save my hair! Add doc about "no module named <blah>"
Reported by: | anonymous | Owned by: | Jacob |
---|---|---|---|
Component: | Documentation | Version: | dev |
Severity: | Normal | Keywords: | python import |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I spent the better part of half a day whacking against a "no module named apps.wiki" problem. Please, please, save the next guy's hair follicles.
I went into Python and did "import sys" and "print sys.path" and yep, the directory was on the path! But still, no joy. Finally after a long time I dimly remembered that the "init.py" file might be needed in "apps," and sure enough once I put the file there, "Joy!" But my poor scalp may never be the same. So, two quick docs-suggestions:
(1) Remind folks, at the appropriate time and place, about PYTHONPATH and maybe ".bashrc." Point them, of course, to a suitable existing page, e.g. at the Python site.
(2) Remind them specifically about this "amazingly obscure init.py thing," because Python's non-message is absolutely uninformative. I literally "solved" this problem by accident.
It is certainly very easy for people who work with a computer programming language every working day, to lose track of just how incomprehensibly frustrating an incomprehensible problem can be, and this is certainly one of those. I think it's safe to say that this is going to "bite" every single Django noobie ... and it also bit me, and I TOO work with Python every single workday. So, at the various places in the intro and the task-specific docs on the site where the user's likely to encounter this source of baldness, "just a few words, please."
Thanks.
Change History (7)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
I also had this problem, but for a different reason. Also include that if people are using 2 different versions of python (as is required by CentOS) that they are using the correct version when executing the command.
comment:3 by , 17 years ago
Component: | Django Web site → Documentation |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
This is Python behaving exactly like Python should. Engineering around this issue will only confuse those that understand how Python works, and the only was I can see to document the issue is to duplicate large sections of "How to program in Python" documentation - which is documented better elsewhere, and would only serve to detract from the clarity of existing documentation.
I'm marking this as wontfix unless you have a _specific_ suggestion of what documentation can be improved. If you have a specific suggestion (add XXX to section Y of foo.txt), feel free to repoen the ticket.
comment:4 by , 16 years ago
I'm currently being hit by this same problem. While I agree with Russ that Python is acting like it should, the real issue is that Django is swallowing up a traceback, and in doing so it is preventing me from seeing the real source of the problem.
comment:5 by , 15 years ago
In case someone else gets here looking to save their hair.
I have had this error when nothing has been changed on the site, but I have added an app with the same name somewhere else on the pythonpath. Eg. have an "events" app in my django project and then create an "events" folder elsewhere on the pythonpath.
comment:6 by , 14 years ago
Replying to floguy:
I'm currently being hit by this same problem. While I agree with Russ that Python is acting like it should, the real issue is that Django is swallowing up a traceback, and in doing so it is preventing me from seeing the real source of the problem.
This is the solution for Django.
Django's import_module() function should catch the ImportError, add information about the origin of the app_name variable,
and then re-throw the ImportError with the additional Django relevant details added.
This is an exception that Django can anticipate, so it should really have better handling.
comment:7 by , 12 years ago
Easy pickings: | unset |
---|---|
Severity: | → Normal |
Type: | → Uncategorized |
UI/UX: | unset |
this definetly saved my day! thanks a lot! I spent a lot of time finding out what happened after copying my app to a new django installation. The problem was solved easily by adding the init.py
I think this issue or feature should be bolded in the Django Tutorial, with something saying "Just make sure this file is in apps folder in case of a module not found".
BTW: I should note that "apps/wiki" DID have the "init.py" file ... didn't matter. I do not, however, profess to be an expert on "the Python facility formerly known as: the module that goes 'ni!'" The problem was opaque, the message (no fault of Django's!) WORSE THAN useless, the hours lost were real, and it just didn't have to be this way. (But the beer was good; thanks I feel better now.)