I do almost the same thing, but instead of importing settings_local.py in settings.py, I import setting.py in settings_local.py and then just run my dev server by doing something like "python manage.py --settings settings-local runserver" which works well for my use case.
On Sep 5, 8:42 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I'm using a structure of: > > svn_project/ > src/ > apps/ > app1/ -> ext > app2/ -> ext > media/ > templates/ > > This moves all of my Python code into a top level directory (src/) so > that Python code, templates, and static files are all logically > separated at the top level. This tends to reinforce the idea that > template and media files can be separately edited by non-programmer > types. It also makes locking down each directory to a different group > a little simpler in that case, both in svn and on the actual file- > system. Further, for serving up static files, I can directly point my > nginx config at the media directory w/o worrying about accidentally > exposing my src directory since it is not a parent to the media > directory. > > As for apps, each project src/ contains a generic apps/ path, which is > where I put the apps for the project that I'm simply not going to > bother to make generic or re-usable. Re-usable or 3rd party apps get > externals linked directly in src/ to svn projects that I put in a > different spot in the repo. This also avoids any name collisions > between 3rd party apps and my project-specific apps, since the project- > specific ones are always in the "apps." namespace. > > For settings, I personally find that a combination of a version > controlled settings.py and a non-vc settings_local.py works best for > my needs. settings.py imports settings_local.py. settings_local.py is > short and contains some root paths to the deployment location, > database name/password, and admin emails that differ between prod, > test, and devl environments. It rarely if ever changes between > versions, unless I reorganize my directory structure or need to add a > new localized value. It's not 100% perfect for hunting down old > version bugs, but I have yet to run into any real problem with doing > it that way as most of my breaking changes happen in the version > controlled settings.py. > > On Sep 4, 9:10 am, Robert Dailey <[EMAIL PROTECTED]> wrote: > > > Hi, > > > First, let me start by explaining what my goals are: > > - Have a django project & its apps in version control > > - Have all of the templates the apps will use in the same version > > control > > - Have all static content (images, css, etc) in the same version > > control. > > > So far, this is the directory structure I've come up with: > > > django/ > > my_project/ > > app1/ > > app2/ > > templates/ > > static/ > > images/ > > styles/ > > > Is this a good structure? Using this structure, I can work on > > everything involved in making my website through a single working copy > > in Subversion. Do you guys have any better suggestions? My main > > concern with the structure I presented above is how I will configure > > Apache2 to handle serving static content. Also, the fact that Django > > requires an absolute path for the templates directory makes this more > > of a management nightmare. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
