On Tue, 2008-03-25 at 00:01 -0500, Joseph Kocherhans wrote: > So, I've worked up a new patch that works for me with manage.py and > django-admin.py both with the settings flag and the environment > variable. The only real difference from the original is that now in > setup_environ, DJANGO_SETTINGS_MODULE is only set if it hasn't been > already. If the DJANGO_SETTINGS_MODULE was set to 'localsettings', > setup_environ was munging it to 'myproject.localsettings' I don't > really use setup_eviron, ever, so I'm not sure if this will have any > unintended consequences, but it seems reasonable to me. Anyone care to > test this or comment before I check it in? > > http://code.djangoproject.com/ticket/5943
Short version: Hmm ... here's a nice trapdoor. Just stand on this. Pay no attention to the alligator noises coming from underneath or the man playing with the rope that releases the catch. I'm sure nothing will go wrong... :-) Longer version... My problem with this is that if DJANGO_SETTINGS_MODULE is set to something quite different from the passed in "--settings" it's going to lead to unintended problems. You're working around the case where they are aliases for the same module, but what if they're pointing in different directions? It would be nice to have no dependency on DJANGO_SETTINGS_MODULE after the initial entry point. We may even be close to that now, but "from django.conf import settings" uses the environment variable to import things. So if it's set incorrectly, you'll get the wrong settings imported. This is definitely a problem for those using setup_environ(), which was the way we encourage people to run scripts if they want the same setup as Django would operate under. In fact, doesn't this kind of happen now if you set DJANGO_SETTINGS_MODULE to something entirely random and then pass in a different settings file with your patch. The settings import looks like it won't work. If somebody calls setup_environ() and then "from django.conf import settings", it'd be nice if they actually imported the settings from the module they passed into seutp_environ(), rather than some stray environment variable (env variables should always be the final fallback if nothing more immediate like a "--settings" variable is specified). Does your patch handle this case, or should we be thinking of some other way to get the settings import location? At the moment we're using os.environ as a way to carry around the string name to import. Maybe we should be actually doing the import in setup_environ (which is a lazy import) and maybe passing in the location to eventually import from to the LazySettings class so that it doesn't have to use DJANGO_SETTINGS_MODULE in the case that comes from setup_environ(). Regards, Malcolm -- The early bird may get the worm, but the second mouse gets the cheese. http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
