Re: INSTALLED_APPS partially shown in admin with mod_python
Kilian CAVALOTTI
> a developement period using the integrated server. After some struggle,
> I finally have a (quite) working installation. But the admin module
> shows a really weird quirk. I have two custom applications, listed in
> INSTALLED_APPS, and which are correctly shown in admin using the
> integrated server. But when I use mod_python, one of those custom apps
> is missing from the admin page.
> Weirder is the fact that I can successfully access to the 'should-be'
> admin URLs for adding or editing hostManage objects
> (admin/hostManage/.../add/). So the hostManage app seems to be
> integrated and working (I actually can manage objects with direct URLs),
> but it's not shown on the main admin page. Any idea why?
I narrowed the problem to the fact that get_apps() from django.db.models
does not return the same list when called from mod_python or from the
integrated server. More precisely, it seems that for one of my
applications, in db/models/loading.py, the load_app() function checking
for 'models' attribute behaves differently according to the server used.
The hasattr(mod, 'models') call returns False for one of the
applications using mod_python, and True for the same application using the
integrated server. Thus, it's not listed in _app_list, and is not
displayed on the admin page.
I added an 'assert False, h', with h = hasattr(mod, 'models') in the
load_app() function from db/models/loading.py, and get the following with
mod_python:
assert False, h ...
▼ Local vars
Variable Value
app_name 'dNA.hostManage'
h False
mod <module 'dNA.hostManage' from '/var/www/dNA/hostManage/__init__.pyc'>
I removed *.pyc, and checked permissions on my folders and directories, but
they seems to be ok since I the hasattr(mod, 'models') works from the
shell:
>>> mod = __import__('hostManage', '', '', ['models'])
>>> mod
<module 'hostManage' from '/var/www/dNA/hostManage/__init__.pyc'>
>>> hasattr(mod, 'models')
True
After that, I'm truly lost, and I get no idea of what could be wrong. Did
anyone has any idea why the hasattr function could return different values
according to the server used?
--
Kilian CAVALOTTI Administrateur réseaux et systèmes
UPMC / CNRS - LIP6 (C870)
8, rue du Capitaine Scott Tel. : 01 44 27 88 54
75015 Paris - France Fax. : 01 44 27 70 00
Malcolm Tredinnick
On Thu, 2006-07-27 at 18:36 +0200, Kilian CAVALOTTI wrote:
[...]
> After that, I'm truly lost, and I get no idea of what could be wrong. Did
> anyone has any idea why the hasattr function could return different values
> according to the server used?
Aargh! Can you make a ticket with these details so that we don't lose
them, please (I have flagged this email to look at later, too). This --
the get_apps() and get_models() code -- is a slight hairy, but currently
necessary area, trying to avoid multiple imports and the like for
models. So it's going to take a little bit of work to completely debug
it (again). Assign the ticket to me (mtredinnick) so that it shows up on
my searches.
Thanks for doing the investigation you did, though. That helps narrow it
down a *lot*. It will help when I get some time to look at this. This is
exactly the information
Regards,
Malcolm
Kilian CAVALOTTI
> Aargh! Can you make a ticket with these details so that we don't lose
> them, please (I have flagged this email to look at later, too).
Sure. It's done as ticket #2438.
> This --
> the get_apps() and get_models() code -- is a slight hairy,
:)
> Thanks for doing the investigation you did, though. That helps narrow it
> down a *lot*. It will help when I get some time to look at this. This is
> exactly the information
That's a pleasure to dig around in django code, as it's globally clear, and
well structured, it's not too difficult to identify where the problems are
located. But in that case, I'm banging my head against the fact that
hasattr() is a python core function, and I can't figure out why the
returned results depends on the server used. I'll try to investigate a
little more and post my findings here, if any.
Regards,
favo
Malcolm Tredinnick
On Thu, 2006-07-27 at 22:40 +0200, Kilian CAVALOTTI wrote:
> On Thursday 27 July 2006 18:48, Malcolm Tredinnick wrote:
> > Aargh! Can you make a ticket with these details so that we don't lose
> > them, please (I have flagged this email to look at later, too).
>
> Sure. It's done as ticket #2438.
>
> > This --
> > the get_apps() and get_models() code -- is a slight hairy,
>
> :)
>
> > Thanks for doing the investigation you did, though. That helps narrow it
> > down a *lot*. It will help when I get some time to look at this. This is
> > exactly the information
>
> That's a pleasure to dig around in django code, as it's globally clear, and
> well structured, it's not too difficult to identify where the problems are
> located. But in that case, I'm banging my head against the fact that
> hasattr() is a python core function, and I can't figure out why the
> returned results depends on the server used. I'll try to investigate a
> little more and post my findings here, if any.
I was looking at this problem a bit more today and I must admit that I'm
a bit stumped at the moment. A few questions, though, which may help
narrow down the cause a bit (I cannot repeat the problem over here, so
hopefully you can test your failing case and we'll all be
enlightened)...
1. In the original django-users thread on this, you said you were
importing hostManage as dNA.hostManage, but in your example above, you
are only importing it directly (using the fact that '.' is on the
PYTHONPATH). Does the command- line test work if you import it using the
same qualified path as in your INSTALLED_APPS tuple?
2. If you remove dNA.zoneConf from the INSTALLED_APPS list, or move it
further down the list (if the former test isn't possible), does the
problem still occur?
3. One difference between the standard mod_python setup and the
environment that manage.py shell gives you is that the latter case puts
the /var/www/dNA/ directory on the Python path, whereas I suspect your
mod_python configuration will only have /var/www/ in your PythonPath?
(plus the standard system paths). Is this correct (in your
configuration)? Does the problem go away if you add / var/www/dNA/ to
the Python path directive?
4. Are the permissions in /var/www/dNA/hostManage/ exactly the same as
in dNA/zoneConf? In particular, does the webserver process have
permission to read the models.py file?
5. Are you using a hostManage/models.py file, or hostManage/models/...
files (in a directory)?
I am suspecting that there is some interaction between the permissions
on the files you have (*.py and/or *.pyc files) and the web server's
permissions to read those files.
Regards,
Malcolm
favo
a snapshot of my apps' Directory Structure:
\myapp\models\
\myapp\models\__init__.py
\myapp\models\category.py -- a model, manually specify app_label =
"myapp" in Meta
\myapp\urls.py -- import category.py
in urls.py, if we import category.py then the apps disapper in admin
dashboard when use apache server(but enable in integrated server). I
move the import of category in urls.py all server worked.
integrated django server import all apps in the same order of
INSTALL_APPS at initial(in validator model progress) but mod_python
don't did it.
and model need import as the order of INSTALL_APPS, there's some hack
or dependence.
I guess that's the reason.
favo
Malcolm Tredinnick
> I find a way to repeat this problems
>
> a snapshot of my apps' Directory Structure:
> \myapp\models\
> \myapp\models\__init__.py
> \myapp\models\category.py -- a model, manually specify app_label =
> "myapp" in Meta
> \myapp\urls.py -- import category.py
Do you import it just as "from models import category" or some other
way?
This information looks useful, but I can't replicate the problem quite
yet with this set up. But it gives me something to work with at least.
Thanks for narrowing it down a bit.
> in urls.py, if we import category.py then the apps disapper in admin
> dashboard when use apache server(but enable in integrated server). I
> move the import of category in urls.py all server worked.
What do you mean when you say you move it? You move it later in the
file? Or remove it entirely? Can you post your urls.py file so that I
can see how you are ordering things -- it's a little hard to work out
what is changing from the description you have given so far.
Regards,
Malcolm
favo
urls.py is quite simple:
from myproject.myapp.models.category import Category
urlpatterns = patterns('',
...
)
since I only have apache mod_python on my production server and my app
is very large, very hard to debug. I 'll try to set mode_python on my
develop-station and simplity the progress to replicate the problem
first.
Thanks Malcolm
Kilian CAVALOTTI
First of all, I'm really sorry about the delay, I was on my
no-internet-no-cellphone vacation week, and just got your message today. I
ran all the following tests with today's SVN (r3529).
On Tuesday 01 August 2006 07:11, Malcolm Tredinnick wrote:
> 1. In the original django-users thread on this, you said you were
> importing hostManage as dNA.hostManage, but in your example above, you
> are only importing it directly (using the fact that '.' is on the
> PYTHONPATH). Does the command- line test work if you import it using the
> same qualified path as in your INSTALLED_APPS tuple?
Yep, it seems so:
In [9]: __import__('hostManage', '', '', ['models'])
Out[9]: <module 'hostManage' from 'hostManage/__init__.pyc'>
In [10]: __import__('dNA.hostManage', '', '', ['models'])
Out[10]: <module 'dNA.hostManage'
from '/var/www/dNA/../dNA/hostManage/__init__.pyc'>
> 2. If you remove dNA.zoneConf from the INSTALLED_APPS list, or move it
> further down the list (if the former test isn't possible), does the
> problem still occur?
If I remove dNA.zoneConf from the INSTALLED_APPS list, the admin interface
only shows the Auth app, ie. the hostManage application does not reappear.
If I swap the custom applications order (dNA.hostManage, then
dNA.zoneConf), I still get the same beahviour: the zoneConf app is shown
in admin, but the hostManage one is not.
> 3. One difference between the standard mod_python setup and the
> environment that manage.py shell gives you is that the latter case puts
> the /var/www/dNA/ directory on the Python path, whereas I suspect your
> mod_python configuration will only have /var/www/ in your PythonPath?
Right.
> (plus the standard system paths). Is this correct (in your
> configuration)? Does the problem go away if you add / var/www/dNA/ to
> the Python path directive?
If I replace /var/www/ with /var/www/dNA/, I get:
EnvironmentError: Could not import settings 'dNA.settings'
If I keep /var/www and /var/www/dNA in PythonPath, that's the same old
song: zoneConf appears in admin, but hostManage not.
> 4. Are the permissions in /var/www/dNA/hostManage/ exactly the same as
> in dNA/zoneConf? In particular, does the webserver process have
> permission to read the models.py file?
Yep.
$ ls -al /var/www/dNA/{hostManage,zoneConf}/models.py
-rw-rw-r-- 1 iadmin www-data 8595 Jul 27
18:06 /var/www/dNA/hostManage/models.py
-rw-rw-r-- 1 iadmin www-data 6471 Jul 26
17:38 /var/www/dNA/zoneConf/models.py
> 5. Are you using a hostManage/models.py file, or hostManage/models/...
> files (in a directory)?
I use a models.py file.
The really weird part is that hostManage and zoneConf are really the same
kind of applications, each in a subdirectory in /var/www/dNA, with the
exact same permissions; I guess that if it was about mod_python/apache
configuration, none would be displayed. Here, only one is shown in admin,
but they both work correctly when accessing the .../add or .../delete
URLs.
Please do not hesitate to ask for more details if needed.