On Aug 15, 1:15 pm, Yuri Baburov <[email protected]> wrote:
> Hi all,
>
> I'm trying to figure out correct overall and settings path usage
> strategy for my Django applications.
> What I am experiencing now is that settings.py is imported 4 times on
> "python manage.py runserver" command,
> twice as "settings", and twice as "myapp.settings", given that my
> project is named "myapp".
> It also doesn't care if I set DJANGO_SETTINGS_MODULE env option and
> PYTHONPATH env option.
>
> My desire is to make it use "settings", and don't ever use project
> prefix "myapp."
Personally I believe that eliminating the project prefix is a bad
idea. By doing that you start to push to much stuff into global module
namespace and too much change of a conflict.
What I would suggest is experimenting with standardising on one prefix
and having everything internally reference via that no matter what the
project directory is called. You can then set up a dummy module as
entry point.
> Because this will cause much greater app reusability in different
> projects, because of "blog" project and "blog" application possible
> import clashes (and weird errors from urlconf loader), because I want
> to be able to rename project at any moment, because i want "111" or
> "project-v1.1" to be also correct project folders. This is my general
> rule: my apps shouldn't start with project prefix.
So for your example, do the following:
import imp
import sys
import os
djangosite = imp.new_module('djangosite')
djangosite.__path__ = [ '/some/path/projects/projects-v1.1' ]
djangosite.__file__ = '/some/path/projects/projects-v1.1/
__init__.py'
sys.modules['djangosite'] = djangosite
os.environ['DJANGO_SETTINGS_MODULE'] = 'djangosite.settings'
Doing this also means you do not even need the parent projects
directory in sys.path, which is effectively what runserver does as it
adds it only long enough to import the __init__.py file as package
root and then removes the directory.
Anyway, within urls.py and all your code you could then always perform
import references as 'djangosite.etc.etc'. With it standardised, then
quite easy to move stuff between site implementations or rename site
directory and not have to change everything in it.
This does mean that __init__.py in root of Django site package should
always be empty, but normally it is anyway.
Another thing to consider is creating another dummy module entry point
for a directory holding all your reusable applications. This one could
be called 'djangoapps' with references always made via that path.
> So I was struck when I've found the following lines in setup_environ:
>
> if original_settings_path:
> os.environ['DJANGO_SETTINGS_MODULE'] = original_settings_path
> else:
> os.environ['DJANGO_SETTINGS_MODULE'] = '%s.%s' %
> (project_name, settings_name)
>
> Why it does so?
>
> Next, I found why setup_environ is called 4 times: twice with
> original_settings_path = None, twice with original_settings_path =
> 'myapp.settings' (and giving the following entry in sys.modules:
> <module 'myapp.settings' from
> '/Projects/django/myapp/../myapp/settings.pyc'>).
> Twice is because of autoreloader, which spawns new process.
>
> So, to summarize:
>
> settings is loading 4 times because it's loading twice as "settings"
> from manage.py module, and twice as "work.settings" from
> django.core.management.get_commands, see a piece of code below:
>
> # Find the project directory
> try:
> from django.conf import settings
> module = import_module(settings.SETTINGS_MODULE)
> project_directory = setup_environ(module,
> settings.SETTINGS_MODULE)
> except (AttributeError, EnvironmentError, ImportError, KeyError):
> project_directory = None
>
> Ok, runserver process spawning is an exception to other commands, so I
> now want to remove only "work.settings" imports. What should I do? Is
> there something we should improve? Is there something we should
> document?
> I'll be happy to make any required patches or writings.
>
> Currently my fix is to patch setup_environ:
> os.environ['DJANGO_SETTINGS_MODULE'] = '%s' % settings_name
>
> And I commented these lines, I don't understand why they are needed at
> all with my setup, they won't make project directory work without
> __init__.py (and in other cases it can't be imported):
>
> # Import the project module. We add the parent directory to PYTHONPATH to
> # avoid some of the path errors new users can have.
> #sys.path.append(os.path.join(project_directory, os.pardir))
> #project_module = import_module(project_name)
> #sys.path.pop()
And here is the stupid code which temporarily adds it to sys.path as I
explained.
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" 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/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
