>An idea: It could be a new settings module d.s.like_perforce, >which finds the settings-file like described, evals it and reexports >the settings it contains. That way everything will still work >like normal for the rest of us (no nasty surprises because you >cd to someplace down-path from a settings.py file).
Yes, please, if you do stuff like this - dynamic settings lookup by path traversal - make it so that it can be easily disabled. /me really _hates_ things like this, because it's bound to produce weird problems because of being in a different path. Sample: I layout projects in $HOME/project/ and have a django/ below that (so I can have different users on my system using different django releases), stuff/ and cms/ below that (my main app repos with django that are reused in several projects) and then for example a rfc1437/ for the actual project directory that only contains project wide templates, settings files (different ones for prod, dev and testing) and url patterns. So apps aren't contained in a project directory and switching context would lose me the active settings file (and switching settings files when you use "dynamic lookup along the path structure for a well known name" is a pain, as you need to rename files). Oh, and setting up such a system for production is really a pain, you _want_ to be able to give a definitive location of your settings file. So regardless of what you add - as I can see that the above dynamic lookup might be nice for dev I am not absolutely against it - please keep the "override settings location by environment variable" working. bye, Georg
