> A modern Django project is a collection of apps. Files are looked up under > conventional paths within apps. Modules (especially the settings module) > can live anywhere on $PYTHONPATH. Actually, there's not such thing as a > project root. > > For instance, instead of using TEMPLATE_DIRS, project-wide templates can > go into an "myproject" application. You need one anyway as soon as you > write a custom template tag or filter. > > There are two special cases that don't fit into apps: STATIC_ROOT and > MEDIA_ROOT. (Technically, there's ALLOWED_INCLUDE_ROOTS too, but it isn't > commonly used.) >
You can't just say "there is a solution I use, that isn't codified or widely used but solves the problem" and then waive your hand and have the problem go away. TEMPLATE_DIRS, FIXTURES_DIRS, and STATIC_FILES_DIRS are equally special cases unless and until a "project app" is the codified way to do it. Best practice or not, PROJECT_PATH/DIR/ROOT/ETC is common practice to avoid boilerplate. Relative paths for TEMPLATE_DIRS (& others) via Os.Path.Join is a straightforward solution that provides a clean conceptual runway from development to production. Sure the project as a directory analogy isn't a perfect one, but it is a useful first order approximation. For local development, it's certainly fine to store the code in > /home/myproject, compile the static files in /home/myproject/static, and > uploading the media files in /home/myproject/media, and it's convenient to > express that with relative paths. But it's hardly a best practice in > production — at least, not until you've spent 30 seconds thinking about it. > > Django leaves it up to the developer to structure the settings for > different environments. This means we cannot provide a "development only" > settings template. > Django doesn't provide an easy way to distinguish between Dev and Produciton environments (which I think is a separate discussion), Agreed. However, a default that works for development with the information that "you shouldn't do this in production, here's a link to how you should" is far better than nothing. Especially when the nothing is going to lead to people searching for a solution to usually find the default that works for development without the caveat. The current setup gets people to the same "ok for dev" state with more work and less knowledge. I could get behind a proposal to have a "project app" but I'd want to flush out the implications -- right now I'm still +1 on PROJECT_PATH and +0 on "project app". T FWIW, this is a working draft of a default settings file I like that addresses most of these issues: https://github.com/tedtieken/django-project-skel/blob/master/project_name/settings.py (would appreciate constructive criticism offline) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/tw2TfcglfAAJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
