Discussion:
Relative path support for TEMPLATE_DIRS and others in settings.py (django ticket 694)
(too old to reply)
Ben Porter
2012-12-22 21:35:59 UTC
Permalink
Hi,

As per the suggestion in the ticket
(https://code.djangoproject.com/ticket/694), I'm starting a thread for
discussing the issue. Please see the ticket for complete context, but in
summary: the TEMPLATE_DIRS list in settings.py accepts only absolute paths
- and many django installations use different absolute paths (between
different developers, development vs. deployment, deployed on different
servers, etc...). Furthermore, many work around this by modifying the
settings.py file to compute the absolute path from a relative path
(see http://stackoverflow.com/questions/550632/favorite-django-tips-features).
This is a workaround, not a solution.

I would like to see support for relative paths. It seems the solution is
simple, but I wonder if there is some compelling reason to require absolute
paths?

- Ben
--
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/-/CF3Whc03Eu4J.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Florian Apolloner
2012-12-22 21:59:09 UTC
Permalink
Hi,
Post by Ben Porter
I would like to see support for relative paths. It seems the solution is
simple, but I wonder if there is some compelling reason to require absolute
paths?
It would seem so but it is everything but simple: First of, for a relative
path one needs a base path to join with, what is that? In your example it's
the project root, Django doesn't have such thing as a project root. All
that Django requires is a settings module which is importable (and not even
that if you call settings.configure() yourself).

Secondly if you were to suggest the cwd (current working directory) this
won't work either since many deployment solutions change that.

That said I am in agreement with the answers of the other core devs on the
ticket and won't support this feature.

Best regards,
Florian
--
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/-/ST70EsTH33sJ.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Shai Berger
2012-12-22 22:17:42 UTC
Permalink
X-Received: by 10.50.196.135 with SMTP id im7mr6750164igc.1.1356214674470;
Sat, 22 Dec 2012 14:17:54 -0800 (PST)
X-BeenThere: django-developers-/***@public.gmane.org
Received: by 10.50.36.168 with SMTP id r8ls8393945igj.40.canary; Sat, 22 Dec
2012 14:17:48 -0800 (PST)
X-Received: by 10.42.27.7 with SMTP id h7mr13624101icc.13.1356214668244;
Sat, 22 Dec 2012 14:17:48 -0800 (PST)
X-Received: by 10.42.27.7 with SMTP id h7mr13624100icc.13.1356214668234;
Sat, 22 Dec 2012 14:17:48 -0800 (PST)
Received: from smtp145.dfw.emailsrvr.com (smtp145.dfw.emailsrvr.com. [67.192.241.145])
by gmr-mx.google.com with ESMTPS id vb4si705970igb.2.2012.12.22.14.17.48
(version=TLSv1/SSLv3 cipher=OTHER);
Sat, 22 Dec 2012 14:17:48 -0800 (PST)
Received-SPF: pass (google.com: domain of shai-9mtU2oJkgntWk0Htik3J/***@public.gmane.org designates 67.192.241.145 as permitted sender) client-ip=67.192.241.145;
Received: from localhost (localhost.localdomain [127.0.0.1])
by smtp4.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id C09313A029C;
Sat, 22 Dec 2012 17:17:47 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp4.relay.dfw1a.emailsrvr.com (Authenticated sender: shai-AT-platonix.com) with ESMTPSA id 6E2CC3A024F;
Sat, 22 Dec 2012 17:17:47 -0500 (EST)
User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )
In-Reply-To: <b8b67ae2-8630-497f-b193-dc3758c031f8-/***@public.gmane.org>
X-Shai-Sent-From: Home
X-Original-Sender: shai-9mtU2oJkgntWk0Htik3J/***@public.gmane.org
X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com:
domain of shai-9mtU2oJkgntWk0Htik3J/***@public.gmane.org designates 67.192.241.145 as permitted sender) smtp.mail=shai-9mtU2oJkgntWk0Htik3J/***@public.gmane.org
Precedence: list
Mailing-list: list django-developers-/***@public.gmane.org; contact django-developers+owners-/***@public.gmane.org
List-ID: <django-developers.googlegroups.com>
X-Google-Group-Id: 1042074780459
List-Post: <http://groups.google.com/group/django-developers/post?hl=en_US>, <mailto:django-developers-/***@public.gmane.org>
List-Help: <http://groups.google.com/support/?hl=en_US>, <mailto:django-developers+help-/***@public.gmane.org>
List-Archive: <http://groups.google.com/group/django-developers?hl=en_US>
Sender: django-developers-/***@public.gmane.org
List-Subscribe: <http://groups.google.com/group/django-developers/subscribe?hl=en_US>,
<mailto:django-developers+subscribe-/***@public.gmane.org>
List-Unsubscribe: <http://groups.google.com/group/django-developers/subscribe?hl=en_US>,
<mailto:googlegroups-manage+1042074780459+unsubscribe-/***@public.gmane.org>
Archived-At: <http://permalink.gmane.org/gmane.comp.python.django.devel/37487>

Hi,
Post by Florian Apolloner
Post by Ben Porter
I would like to see support for relative paths. It seems the solution is
simple, but I wonder if there is some compelling reason to require
absolute paths?
It would seem so but it is everything but simple: First of, for a relative
path one needs a base path to join with, what is that? In your example it's
the project root, Django doesn't have such thing as a project root.
You are right, but that might be the root of the problem (no pun intended).
Django doesn't have a concept of a project root, and (partly as a result)
requires paths to almost anything that isn't a python module to be given as
absolute path.

I think adding an optional "PROJECT_ROOT" or "PROJECT_PATH_BASE" setting,
specifying that other paths can be made relative to it, will remove a
significant amount of boilerplate in settings files, and will not have any of
the problems you name.

Personally, I have yet to see a settings file in a non-trivial Django project
that doesn't do the os.path.join(os.path.dir(__file__), ...) dance. When done
properly, you end up with a function in_proj_dir that is applied to many
settings values. It would be much cleaner, IMO, to have this code defined in
the framework (rather than settings files) and limit the use of code to a
single setting.

My 2 cents,
Shai.
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Daniel Sokolowski
2012-12-28 16:42:04 UTC
Permalink
PROJECT_ROOT is what I have been using myself and seen it done by others so
to me it makes sense to introduce an official setting for this purpose.

-----Original Message-----
From: Shai Berger
Sent: Saturday, December 22, 2012 5:17 PM
To: django-developers-/***@public.gmane.org
Subject: Re: Relative path support for TEMPLATE_DIRS and others in
settings.py (django ticket 694)

Hi,
Post by Florian Apolloner
Post by Ben Porter
I would like to see support for relative paths. It seems the solution is
simple, but I wonder if there is some compelling reason to require
absolute paths?
It would seem so but it is everything but simple: First of, for a relative
path one needs a base path to join with, what is that? In your example it's
the project root, Django doesn't have such thing as a project root.
You are right, but that might be the root of the problem (no pun intended).
Django doesn't have a concept of a project root, and (partly as a result)
requires paths to almost anything that isn't a python module to be given as
absolute path.

I think adding an optional "PROJECT_ROOT" or "PROJECT_PATH_BASE" setting,
specifying that other paths can be made relative to it, will remove a
significant amount of boilerplate in settings files, and will not have any
of
the problems you name.

Personally, I have yet to see a settings file in a non-trivial Django
project
that doesn't do the os.path.join(os.path.dir(__file__), ...) dance. When
done
properly, you end up with a function in_proj_dir that is applied to many
settings values. It would be much cleaner, IMO, to have this code defined in
the framework (rather than settings files) and limit the use of code to a
single setting.

My 2 cents,
Shai.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to
django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.

--

Daniel Sokolowski
http://webdesign.danols.com/
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Luke Plant
2012-12-29 02:07:41 UTC
Permalink
Post by Daniel Sokolowski
PROJECT_ROOT is what I have been using myself and seen it done by others
so to me it makes sense to introduce an official setting for this purpose.
PROJECT_ROOT would still need to be defined inside the settings.py
module, using the os.path.dir(__file__) etc. dance, because it can't be
defined within django code (which doesn't know where your project
lives), and a utility function to do it isn't worth it (it's only one
line, and you don't want your settings file to be doing imports to
Django code).

So I agree with the original WONTFIX here.

I also think that app directories for the template loader is a better
solution, and making a 'project' app if necessary answers the objection.

However, I do see a case for putting the PROJECT_ROOT code into the
settings.py generated by creating a new template, and updating the help
text for TEMPLATE_DIRS and STATICFILES_DIRS to mention it.


Luke
--
The fashion wears out more apparel than the man.
-- William Shakespeare

Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Cal Leeming [Simplicity Media Ltd]
2012-12-29 04:08:27 UTC
Permalink
Since the day I started using Django, I have always used a relative path
for TEMPLATES_DIR.

import os
CURRENT_DIR = os.path.realpath(os.path.dirname(__file__))
TEMPLATE_DIRS = "%s/templates/" % ( CURRENT_DIR, )

Imho, the idea of having to hard code your PROJECT_ROOT is ludicrous.

I understand the arguments being made about relative paths on settings, but
I am yet to come across a project where the above code has not worked.

Could we not have something like this in the settings.py, which in turn
enabled the code pasted above?
TEMPLATE_PATH_RELATIVE=True

Cal
Post by Daniel Sokolowski
Post by Daniel Sokolowski
PROJECT_ROOT is what I have been using myself and seen it done by others
so to me it makes sense to introduce an official setting for this
purpose.
PROJECT_ROOT would still need to be defined inside the settings.py
module, using the os.path.dir(__file__) etc. dance, because it can't be
defined within django code (which doesn't know where your project
lives), and a utility function to do it isn't worth it (it's only one
line, and you don't want your settings file to be doing imports to
Django code).
So I agree with the original WONTFIX here.
I also think that app directories for the template loader is a better
solution, and making a 'project' app if necessary answers the objection.
However, I do see a case for putting the PROJECT_ROOT code into the
settings.py generated by creating a new template, and updating the help
text for TEMPLATE_DIRS and STATICFILES_DIRS to mention it.
Luke
--
The fashion wears out more apparel than the man.
-- William Shakespeare
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Yo-Yo Ma
2012-12-29 04:41:24 UTC
Permalink
-1 FWIW

Computing the root of your project with os.path works just fine and doesn't require another setting... which, btw, could have no sane default.
--
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/-/ZTjEZkT1TLQJ.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Shai Berger
2012-12-29 06:21:20 UTC
Permalink
X-Received: by 10.50.203.9 with SMTP id km9mr9463256igc.7.1356762092467;
Fri, 28 Dec 2012 22:21:32 -0800 (PST)
X-BeenThere: django-developers-/***@public.gmane.org
Received: by 10.50.151.243 with SMTP id ut19ls8164426igb.20.gmail; Fri, 28 Dec
2012 22:21:26 -0800 (PST)
X-Received: by 10.42.215.203 with SMTP id hf11mr27836343icb.17.1356762086501;
Fri, 28 Dec 2012 22:21:26 -0800 (PST)
X-Received: by 10.42.215.203 with SMTP id hf11mr27836342icb.17.1356762086483;
Fri, 28 Dec 2012 22:21:26 -0800 (PST)
Received: from smtp125.dfw.emailsrvr.com (smtp125.dfw.emailsrvr.com. [67.192.241.125])
by gmr-mx.google.com with ESMTPS id d5si3735657iga.1.2012.12.28.22.21.26
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 28 Dec 2012 22:21:26 -0800 (PST)
Received-SPF: pass (google.com: domain of shai-9mtU2oJkgntWk0Htik3J/***@public.gmane.org designates 67.192.241.125 as permitted sender) client-ip=67.192.241.125;
Received: from localhost (localhost.localdomain [127.0.0.1])
by smtp22.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 079A917058C;
Sat, 29 Dec 2012 01:21:26 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp22.relay.dfw1a.emailsrvr.com (Authenticated sender: shai-AT-platonix.com) with ESMTPSA id B99E21703AA;
Sat, 29 Dec 2012 01:21:25 -0500 (EST)
User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )
In-Reply-To: <CAHKQagG0fzKFjtnVsk3uUr5h5yCVKs9o1NL_-sDqkSXzqj=oFg-JsoAwUIsXosN+***@public.gmane.org>
X-Shai-Sent-From: Home
X-Original-Sender: shai-9mtU2oJkgntWk0Htik3J/***@public.gmane.org
X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com:
domain of shai-9mtU2oJkgntWk0Htik3J/***@public.gmane.org designates 67.192.241.125 as permitted sender) smtp.mail=shai-9mtU2oJkgntWk0Htik3J/***@public.gmane.org
Precedence: list
Mailing-list: list django-developers-/***@public.gmane.org; contact django-developers+owners-/***@public.gmane.org
List-ID: <django-developers.googlegroups.com>
X-Google-Group-Id: 1042074780459
List-Post: <http://groups.google.com/group/django-developers/post?hl=en_US>, <mailto:django-developers-/***@public.gmane.org>
List-Help: <http://groups.google.com/support/?hl=en_US>, <mailto:django-developers+help-/***@public.gmane.org>
List-Archive: <http://groups.google.com/group/django-developers?hl=en_US>
Sender: django-developers-/***@public.gmane.org
List-Subscribe: <http://groups.google.com/group/django-developers/subscribe?hl=en_US>,
<mailto:django-developers+subscribe-/***@public.gmane.org>
List-Unsubscribe: <http://groups.google.com/group/django-developers/subscribe?hl=en_US>,
<mailto:googlegroups-manage+1042074780459+unsubscribe-/***@public.gmane.org>
Archived-At: <http://permalink.gmane.org/gmane.comp.python.django.devel/37530>
Post by Cal Leeming [Simplicity Media Ltd]
Since the day I started using Django, I have always used a relative path
for TEMPLATES_DIR.
import os
CURRENT_DIR = os.path.realpath(os.path.dirname(__file__))
TEMPLATE_DIRS = "%s/templates/" % ( CURRENT_DIR, )
The main point of the idea was to enable relative paths without the string
manipulations, that is,

import os
PROJECT_ROOT = os.path.realpath(os.path.dirname(__file__))
TEMPLATE_DIRS = ["templates/"]

It has some merit because TEMPLATE_DIRS is not the only such setting, so
adding the project root to a path is a pattern repeated several times in the
settings file.
Post by Cal Leeming [Simplicity Media Ltd]
Imho, the idea of having to hard code your PROJECT_ROOT is ludicrous.
Nobody suggested any such thing (well, except, maybe, the comments in the
current default project template).

Shai.
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Luke Plant
2012-12-30 23:01:21 UTC
Permalink
Post by Cal Leeming [Simplicity Media Ltd]
Could we not have something like this in the settings.py, which in turn
enabled the code pasted above?
TEMPLATE_PATH_RELATIVE=True
For consistency, we'd need STATICFILES_PATH_RELATIVE,
STATIC_ROOT_PATH_RELATIVE, MEDIA_ROOT_PATH_RELATIVE etc. which is
craziness. Having just one extra setting is a big deal.

There are use cases for all of these being absolute paths (or at least
some of them), and use cases for all of them being relative. We've
already chosen absolute paths, and you can generate absolute from
relative using os.path.realpath etc.

The only option I can is whether we put that snippet of code (e.g.
PROJECT_ROOT=os.path.realpath(os.path.dirname(__file__)) ) into the
settings file generated when starting a new project.

Luke
--
"If we could just get everyone to close their eyes and visualise
world peace for an hour, imagine how serene and quiet it would be
until the looting started" -- Anon

Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Cal Leeming [Simplicity Media Ltd]
2012-12-31 00:58:52 UTC
Permalink
Post by Luke Plant
Post by Cal Leeming [Simplicity Media Ltd]
Could we not have something like this in the settings.py, which in turn
enabled the code pasted above?
TEMPLATE_PATH_RELATIVE=True
For consistency, we'd need STATICFILES_PATH_RELATIVE,
STATIC_ROOT_PATH_RELATIVE, MEDIA_ROOT_PATH_RELATIVE etc. which is
craziness. Having just one extra setting is a big deal.
There are use cases for all of these being absolute paths (or at least
some of them), and use cases for all of them being relative. We've
already chosen absolute paths, and you can generate absolute from
relative using os.path.realpath etc.
The only option I can is whether we put that snippet of code (e.g.
PROJECT_ROOT=os.path.realpath(os.path.dirname(__file__)) ) into the
settings file generated when starting a new project.
+1
Post by Luke Plant
Luke
--
"If we could just get everyone to close their eyes and visualise
world peace for an hour, imagine how serene and quiet it would be
until the looting started" -- Anon
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
ted
2013-01-01 16:45:11 UTC
Permalink
Post by Luke Plant
The only option I can is whether we put that snippet of code (e.g.
PROJECT_ROOT=os.path.realpath(os.path.dirname(__file__)) ) into the
settings file generated when starting a new project.
+1 for adding this to settings, then adding a commented out os.path.join(
PROJECT_ROOT, 'templates') with a brief explanation in the template dirs
section, and the same for static.

Recently, I went through all of the public startproject templates I could
find (and most of their branches): django-project-skel,
django-project-skelleton, and django-skel. In all three projects they use
some form of PROJECT_ROOT and os.path.join(PROJECT_DIR, 'templates').
https://github.com/amccloud/django-project-skel/blob/master/project_name/settings.py
https://github.com/rdegges/django-skel/blob/master/project_name/settings/common.py
https://github.com/alex/django-project-skeleton/blob/master/project_name/settings/base.py

Lincoln loop has in their best practices as
well http://lincolnloop.com/django-best-practices/projects.html#settings

I'm under the impression that this is something that nearly everyone does
-- are there a large number of cases where people explicitly decide not to
use os.path.join and a PROJECT_ROOT variable?

Ted
--
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/-/VVK1CzrP7AcJ.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Aymeric Augustin
2013-01-01 18:28:51 UTC
Permalink
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.)

Static files are collected from the apps into STATIC_ROOT that is then served by the web server. To avoid accidentally leaking Python code over the web, it's a good idea to keep this directory outside of your source tree.

Media files are written by the application server into MEDIA_ROOT. It's a good idea to put them on a separate partition (DoS by filling up / isn't fun), or at least in a directory outside of your source tree, which must be read-only for the web server.

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.

For these reasons, I'm against codifying PROJECT_ROOT and relative paths in Django's default settings files. No amount of "+1 because I'm doing it already" or blog posts will make it a best practice in production.

And developers will keep doing it until sysadmins tell them not to.
--
Aymeric.
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Cal Leeming [Simplicity Media Ltd]
2013-01-01 18:48:59 UTC
Permalink
For the record, the only time I'd suggested using relative paths is for
'TEMPLATE_DIRS' only, I do not use the other two.

Rather than saying "spend 30 seconds thinking about it", could you perhaps
spend 30 seconds explaining why using relative paths for TEMPLATE_DIRS
would be considered a bad thing to do?

Your post makes sense for STATIC_ROOT and MEDIA_ROOT, but it makes no sense
for TEMPLATE_DIRS, imo.

Cal

On Tue, Jan 1, 2013 at 6:28 PM, Aymeric Augustin <
Post by Aymeric Augustin
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.)
Static files are collected from the apps into STATIC_ROOT that is then
served by the web server. To avoid accidentally leaking Python code over
the web, it's a good idea to keep this directory outside of your source
tree.
Media files are written by the application server into MEDIA_ROOT. It's a
good idea to put them on a separate partition (DoS by filling up / isn't
fun), or at least in a directory outside of your source tree, which must be
read-only for the web server.
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.
For these reasons, I'm against codifying PROJECT_ROOT and relative paths
in Django's default settings files. No amount of "+1 because I'm doing it
already" or blog posts will make it a best practice in production.
And developers will keep doing it until sysadmins tell them not to.
--
Aymeric.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Alex Gaynor
2013-01-01 18:54:26 UTC
Permalink
I would like to *strongly* object to adding any notion of root path (and
relative paths with it) to Django. This would be furthering the notion that
a django project is a thing. It's not. You don't hear twisted people
talking about the twisted project root, or any other python package. The
notion of a django project is a bizzare historical relic, and should not be
the basis for future design decisions.

Alex


On Tue, Jan 1, 2013 at 10:48 AM, Cal Leeming [Simplicity Media Ltd] <
Post by Cal Leeming [Simplicity Media Ltd]
For the record, the only time I'd suggested using relative paths is for
'TEMPLATE_DIRS' only, I do not use the other two.
Rather than saying "spend 30 seconds thinking about it", could you perhaps
spend 30 seconds explaining why using relative paths for TEMPLATE_DIRS
would be considered a bad thing to do?
Your post makes sense for STATIC_ROOT and MEDIA_ROOT, but it makes no
sense for TEMPLATE_DIRS, imo.
Cal
On Tue, Jan 1, 2013 at 6:28 PM, Aymeric Augustin <
Post by Aymeric Augustin
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.)
Static files are collected from the apps into STATIC_ROOT that is then
served by the web server. To avoid accidentally leaking Python code over
the web, it's a good idea to keep this directory outside of your source
tree.
Media files are written by the application server into MEDIA_ROOT. It's a
good idea to put them on a separate partition (DoS by filling up / isn't
fun), or at least in a directory outside of your source tree, which must be
read-only for the web server.
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.
For these reasons, I'm against codifying PROJECT_ROOT and relative paths
in Django's default settings files. No amount of "+1 because I'm doing it
already" or blog posts will make it a best practice in production.
And developers will keep doing it until sysadmins tell them not to.
--
Aymeric.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
--
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Cal Leeming [Simplicity Media Ltd]
2013-01-01 18:54:39 UTC
Permalink
Just re-read my post, and realised it may have come across a bit loaded
(was replying very quickly)

No insult was intended, and it's a genuine question

Cal

On Tue, Jan 1, 2013 at 6:48 PM, Cal Leeming [Simplicity Media Ltd] <
Post by Cal Leeming [Simplicity Media Ltd]
For the record, the only time I'd suggested using relative paths is for
'TEMPLATE_DIRS' only, I do not use the other two.
Rather than saying "spend 30 seconds thinking about it", could you perhaps
spend 30 seconds explaining why using relative paths for TEMPLATE_DIRS
would be considered a bad thing to do?
Your post makes sense for STATIC_ROOT and MEDIA_ROOT, but it makes no
sense for TEMPLATE_DIRS, imo.
Cal
On Tue, Jan 1, 2013 at 6:28 PM, Aymeric Augustin <
Post by Aymeric Augustin
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.)
Static files are collected from the apps into STATIC_ROOT that is then
served by the web server. To avoid accidentally leaking Python code over
the web, it's a good idea to keep this directory outside of your source
tree.
Media files are written by the application server into MEDIA_ROOT. It's a
good idea to put them on a separate partition (DoS by filling up / isn't
fun), or at least in a directory outside of your source tree, which must be
read-only for the web server.
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.
For these reasons, I'm against codifying PROJECT_ROOT and relative paths
in Django's default settings files. No amount of "+1 because I'm doing it
already" or blog posts will make it a best practice in production.
And developers will keep doing it until sysadmins tell them not to.
--
Aymeric.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Florian Apolloner
2013-01-01 19:36:31 UTC
Permalink
Hi,

On Tuesday, January 1, 2013 7:48:59 PM UTC+1, Cal Leeming [Simplicity Media
Post by Cal Leeming [Simplicity Media Ltd]
Rather than saying "spend 30 seconds thinking about it", could you perhaps
spend 30 seconds explaining why using relative paths for TEMPLATE_DIRS
would be considered a bad thing to do?
I don't think that per se it would be a bad thing to do, but then you could
also just dump the project name (from startproject) into INSTALLED_APPS and
have the same effect (plus you can have project templatetags and filters,
yay :)) as Aymeric already tried to explain. I guess your point for
relative TEMPLATE_DIRS is only that you can have PROJECT_DIR + templates
which is already fullfiller by the app template-loader in a much cleaner
way imo.

I hope that clears things up a bit.

Cheers,
Florian
--
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/-/xuVeOmwI_8AJ.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Cal Leeming [Simplicity Media Ltd]
2013-01-01 20:47:19 UTC
Permalink
Just realised why this has been so heavily debated, and just discovered
something new.

https://docs.djangoproject.com/en/dev/ref/templates/api/#loader-types
django.template.loaders.app_directories.Loader

If 'myproject.polls' is placed into INSTALLED_APPS then Django will look at
'/path/to/myproject/polls/templates/' for the templates.

I didn't even know about app_directories loader, and using it sounds much
cleaner than having to use relative paths.

In regards to the other two vars (media root etc), as stated before, those
should really be deployment specific and not relative, this is a devops
problem not a code problem.

As such, I'm now -9000 on supporting relative paths.

Thanks for explaining this Florian - makes a lot more sense now.

Cal
Post by Florian Apolloner
Hi,
On Tuesday, January 1, 2013 7:48:59 PM UTC+1, Cal Leeming [Simplicity
Post by Cal Leeming [Simplicity Media Ltd]
Rather than saying "spend 30 seconds thinking about it", could you
perhaps spend 30 seconds explaining why using relative paths for
TEMPLATE_DIRS would be considered a bad thing to do?
I don't think that per se it would be a bad thing to do, but then you
could also just dump the project name (from startproject) into
INSTALLED_APPS and have the same effect (plus you can have project
templatetags and filters, yay :)) as Aymeric already tried to explain. I
guess your point for relative TEMPLATE_DIRS is only that you can have
PROJECT_DIR + templates which is already fullfiller by the app
template-loader in a much cleaner way imo.
I hope that clears things up a bit.
Cheers,
Florian
--
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/-/xuVeOmwI_8AJ.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Cal Leeming [Simplicity Media Ltd]
2013-01-01 20:48:31 UTC
Permalink
Also the stupid thing as well, we are already using 'templatetags' and
'filters'.. I just had no idea it supported 'appname/templates' as well.

*doh*

Cal

On Tue, Jan 1, 2013 at 8:47 PM, Cal Leeming [Simplicity Media Ltd] <
Post by Cal Leeming [Simplicity Media Ltd]
Just realised why this has been so heavily debated, and just discovered
something new.
https://docs.djangoproject.com/en/dev/ref/templates/api/#loader-types
django.template.loaders.app_directories.Loader
If 'myproject.polls' is placed into INSTALLED_APPS then Django will look
at '/path/to/myproject/polls/templates/' for the templates.
I didn't even know about app_directories loader, and using it sounds much
cleaner than having to use relative paths.
In regards to the other two vars (media root etc), as stated before, those
should really be deployment specific and not relative, this is a devops
problem not a code problem.
As such, I'm now -9000 on supporting relative paths.
Thanks for explaining this Florian - makes a lot more sense now.
Cal
Post by Florian Apolloner
Hi,
On Tuesday, January 1, 2013 7:48:59 PM UTC+1, Cal Leeming [Simplicity
Post by Cal Leeming [Simplicity Media Ltd]
Rather than saying "spend 30 seconds thinking about it", could you
perhaps spend 30 seconds explaining why using relative paths for
TEMPLATE_DIRS would be considered a bad thing to do?
I don't think that per se it would be a bad thing to do, but then you
could also just dump the project name (from startproject) into
INSTALLED_APPS and have the same effect (plus you can have project
templatetags and filters, yay :)) as Aymeric already tried to explain. I
guess your point for relative TEMPLATE_DIRS is only that you can have
PROJECT_DIR + templates which is already fullfiller by the app
template-loader in a much cleaner way imo.
I hope that clears things up a bit.
Cheers,
Florian
--
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/-/xuVeOmwI_8AJ.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Shai Berger
2013-01-01 23:54:16 UTC
Permalink
X-Received: by 10.49.35.77 with SMTP id f13mr6687595qej.4.1357084472329;
Tue, 01 Jan 2013 15:54:32 -0800 (PST)
X-BeenThere: django-developers-/***@public.gmane.org
Received: by 10.49.94.82 with SMTP id da18ls6213765qeb.26.gmail; Tue, 01 Jan
2013 15:54:19 -0800 (PST)
X-Received: by 10.236.175.7 with SMTP id y7mr22119854yhl.14.1357084459916;
Tue, 01 Jan 2013 15:54:19 -0800 (PST)
X-Received: by 10.236.175.7 with SMTP id y7mr22119853yhl.14.1357084459905;
Tue, 01 Jan 2013 15:54:19 -0800 (PST)
Received: from smtp205.dfw.emailsrvr.com (smtp205.dfw.emailsrvr.com. [67.192.241.205])
by gmr-mx.google.com with ESMTPS id r6si3497484yhc.7.2013.01.01.15.54.19
(version=TLSv1/SSLv3 cipher=OTHER);
Tue, 01 Jan 2013 15:54:19 -0800 (PST)
Received-SPF: pass (google.com: domain of shai-9mtU2oJkgntWk0Htik3J/***@public.gmane.org designates 67.192.241.205 as permitted sender) client-ip=67.192.241.205;
Received: from localhost (localhost.localdomain [127.0.0.1])
by smtp10.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 898E01B8150;
Tue, 1 Jan 2013 18:54:19 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp10.relay.dfw1a.emailsrvr.com (Authenticated sender: shai-AT-platonix.com) with ESMTPSA id 34C6F1B813E;
Tue, 1 Jan 2013 18:54:19 -0500 (EST)
User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )
In-Reply-To: <88AC6B8E-C1FC-4F86-AFD3-B6080F6ABFDD-o/5/jSaJEHk+NdeTPqioyti2O/***@public.gmane.org>
X-Shai-Sent-From: Home
X-Original-Sender: shai-9mtU2oJkgntWk0Htik3J/***@public.gmane.org
X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com:
domain of shai-9mtU2oJkgntWk0Htik3J/***@public.gmane.org designates 67.192.241.205 as permitted sender) smtp.mail=shai-9mtU2oJkgntWk0Htik3J/***@public.gmane.org
Precedence: list
Mailing-list: list django-developers-/***@public.gmane.org; contact django-developers+owners-/***@public.gmane.org
List-ID: <django-developers.googlegroups.com>
X-Google-Group-Id: 1042074780459
List-Post: <http://groups.google.com/group/django-developers/post?hl=en_US>, <mailto:django-developers-/***@public.gmane.org>
List-Help: <http://groups.google.com/support/?hl=en_US>, <mailto:django-developers+help-/***@public.gmane.org>
List-Archive: <http://groups.google.com/group/django-developers?hl=en_US>
Sender: django-developers-/***@public.gmane.org
List-Subscribe: <http://groups.google.com/group/django-developers/subscribe?hl=en_US>,
<mailto:django-developers+subscribe-/***@public.gmane.org>
List-Unsubscribe: <http://groups.google.com/group/django-developers/subscribe?hl=en_US>,
<mailto:googlegroups-manage+1042074780459+unsubscribe-/***@public.gmane.org>
Archived-At: <http://permalink.gmane.org/gmane.comp.python.django.devel/37550>

Hi,

I have to take back my support of PROJECT_ROOT, in view of Aymeric's
arguments. However, now I think he isn't pursuing the conclusions of the
Post by Aymeric Augustin
For instance, instead of using TEMPLATE_DIRS, project-wide templates can go
into an "myproject" application.
"There should be one-- and preferably only one --obvious way to do it". If a
project app is the way to do it, TEMPLATE_DIRS should be deprecated.
Conversely, at the moment, a project app is the non-obvious way to do it (and
it carries with it further non-obviousness, like the importance of the order
of INSTALLED_APPS).

Also, settings with essentially the same behavior:
FIXTURE_DIRS
LOCALE_PATHS
STATICFILES_DIRS (mentioned in contrib.staticfiles docs, but not main settings
doc)
Post by Aymeric Augustin
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.)
Also:
In CACHES: LOCATION when BACKEND is FileBasedCache
In DATABASES: NAME when ENGINE is sqlite3 (relative path accepted here;
granted, sqlite3 is not recommended for production)
FILE_UPLOAD_TEMP_DIR
SESSION_FILE_PATH (for file-based sessions)

Third-party apps may add further such paths, where working data gets stored.

[Good arguments, about best practices for production and how paths relative to
the sources' root are only acceptable for development, snipped]
Post by Aymeric Augustin
For these reasons, I'm against codifying PROJECT_ROOT and relative paths in
Django's default settings files.
But what if we called it "WORK_FILES_ROOT" (or something similar), and made it
clear that it's expected to lie outside the sources?
Post by Aymeric Augustin
No amount of "+1 because I'm doing it already" or blog posts will make it a
best practice in production.
One point to take from those posts and reported practices, is that your
current position does not promote the cause of keeping working-data (and work-
copies of static files) out of the source tree. instead, it promotes
boilerplate coding in settings files, and a dangerous mixing of non-python
source files with work-files.

I think we can (and should) do better -- deprecate the global *_DIRS settings,
include a project app in the default settings (at least as a comment), clarify
the importance of order in INSTALLED_APPS, and make putting the work-files out
of the sources obvious.

My 2 cents,
Shai.
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Victor Hooi
2013-01-02 06:36:23 UTC
Permalink
Hi,

I may have missed it, but has been a fundamental shift in how Django looks
at projects versus applications, and how they should be laid out?

I get the impression from Alex Gaynor's comments above that the concept of
"projects" is on it's way out?

I know there was a change in project layout with Django 1.4, but I thought
things were still more or less the same as before - and projects were still
in.

James Bennett wrote a blog post way back in 2006 about projects versus
applications:

http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/

I'm wondering if anybody from core is interested in updating that to
reflect current best practices, and the future direction of Django?

Cheers,
Victor
Post by Shai Berger
Hi,
I have to take back my support of PROJECT_ROOT, in view of Aymeric's
arguments. However, now I think he isn't pursuing the conclusions of the
Post by Aymeric Augustin
For instance, instead of using TEMPLATE_DIRS, project-wide templates can
go
Post by Aymeric Augustin
into an "myproject" application.
"There should be one-- and preferably only one --obvious way to do it". If a
project app is the way to do it, TEMPLATE_DIRS should be deprecated.
Conversely, at the moment, a project app is the non-obvious way to do it (and
it carries with it further non-obviousness, like the importance of the order
of INSTALLED_APPS).
FIXTURE_DIRS
LOCALE_PATHS
STATICFILES_DIRS (mentioned in contrib.staticfiles docs, but not main settings
doc)
Post by Aymeric Augustin
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
Post by Aymeric Augustin
commonly used.)
In CACHES: LOCATION when BACKEND is FileBasedCache
In DATABASES: NAME when ENGINE is sqlite3 (relative path accepted here;
granted, sqlite3 is not recommended for production)
FILE_UPLOAD_TEMP_DIR
SESSION_FILE_PATH (for file-based sessions)
Third-party apps may add further such paths, where working data gets stored.
[Good arguments, about best practices for production and how paths relative to
the sources' root are only acceptable for development, snipped]
Post by Aymeric Augustin
For these reasons, I'm against codifying PROJECT_ROOT and relative paths
in
Post by Aymeric Augustin
Django's default settings files.
But what if we called it "WORK_FILES_ROOT" (or something similar), and made it
clear that it's expected to lie outside the sources?
Post by Aymeric Augustin
No amount of "+1 because I'm doing it already" or blog posts will make
it a
Post by Aymeric Augustin
best practice in production.
One point to take from those posts and reported practices, is that your
current position does not promote the cause of keeping working-data (and work-
copies of static files) out of the source tree. instead, it promotes
boilerplate coding in settings files, and a dangerous mixing of non-python
source files with work-files.
I think we can (and should) do better -- deprecate the global *_DIRS settings,
include a project app in the default settings (at least as a comment), clarify
the importance of order in INSTALLED_APPS, and make putting the work-files out
of the sources obvious.
My 2 cents,
Shai.
--
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/-/60A8TD_uK58J.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Waylan Limberg
2013-01-02 16:10:04 UTC
Permalink
Post by Victor Hooi
Hi,
I may have missed it, but has been a fundamental shift in how Django looks
at projects versus applications, and how they should be laid out?
I get the impression from Alex Gaynor's comments above that the concept of
"projects" is on it's way out?
I know there was a change in project layout with Django 1.4, but I thought
things were still more or less the same as before - and projects were still
in.
James Bennett wrote a blog post way back in 2006 about projects versus
http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/
I'm wondering if anybody from core is interested in updating that to reflect
current best practices, and the future direction of Django?
James updated his position on that almost exactly one year and one month later:

http://www.b-list.org/weblog/2007/nov/09/projects/

My recollection is that the basic premise discussed in that post has
been the general view of all core developers since that time (if not
before). Search the archives of this list and you'll find various
discussions about this - mostly proposals to update the tutorials to
not use the "project" concept. Unfortunately, no one has stepped up to
do the work.

--
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
ted
2013-01-02 19:19:36 UTC
Permalink
Post by Aymeric Augustin
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
Post by Aymeric Augustin
/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-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Florian Apolloner
2013-01-02 21:17:41 UTC
Permalink
Hi,
Post by ted
FWIW, this is a working draft of a default settings file I like that
https://github.com/tedtieken/django-project-skel/blob/master/project_name/settings.py (would appreciate constructive criticism offline)
Luckily you can already use that due to --template support for
startproject, but here a few comments (Aside from still being violently -1
on it):

* local_settings is imo a bad pattern as they can't easily override
anything without copying it completely into the local_settings (think of
all the settings which are dicts like DATABASES and CACHES)
* Where does LOCAL_SETTINGS come from, are you supposed to set that in
your settings file to get locale_settings imported? Why, if local_settings
are there I want them imported, that is the point of local_settings.
* All the env configuration stuff is just scary and way to specific for a
useful default settings file
* You have way to much stuff in INSTALLED_APPS, most of it is completely
out of scope for a default settings file.
* that applib sys.path magic just makes me cry.

That all said, it's nice if that settings file fits you, but I surely
couldn't do anything with it. This is probably how I would do it (Talking
about a big monolithic project):
project/default_settings.py
test_settings.py
dev_settings.py
production_settings.py

then each of the settings files would do: "from project.default_settings
import *" and then customize stuff as needed (eg: INSTALLED_APPS +=
('debug_toolbar',)). This way all the settings files are clearly separated
and stay readable. Might not be best practices but that's how it works
quite well for me.

Cheers,
Florian
--
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/-/A9l9wk8xT40J.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
ted
2013-01-02 21:26:10 UTC
Permalink
To be clear, I'm not proposing the settings.py file from my github as a
django default. It is what works for me, provided for context.

Florian, the method you use for environment specific settings is one of the
two most common I saw in my survey: local_settings.py being the most
common. Again, best practice vs common practice I don't know.

But again, I'm not proposing my settings.py file as the default, just
provided for context.

T
Post by Florian Apolloner
Hi,
Post by ted
FWIW, this is a working draft of a default settings file I like that
https://github.com/tedtieken/django-project-skel/blob/master/project_name/settings.py (would appreciate constructive criticism offline)
Luckily you can already use that due to --template support for
startproject, but here a few comments (Aside from still being violently -1
* local_settings is imo a bad pattern as they can't easily override
anything without copying it completely into the local_settings (think of
all the settings which are dicts like DATABASES and CACHES)
* Where does LOCAL_SETTINGS come from, are you supposed to set that in
your settings file to get locale_settings imported? Why, if local_settings
are there I want them imported, that is the point of local_settings.
* All the env configuration stuff is just scary and way to specific for a
useful default settings file
* You have way to much stuff in INSTALLED_APPS, most of it is completely
out of scope for a default settings file.
* that applib sys.path magic just makes me cry.
That all said, it's nice if that settings file fits you, but I surely
couldn't do anything with it. This is probably how I would do it (Talking
project/default_settings.py
test_settings.py
dev_settings.py
production_settings.py
then each of the settings files would do: "from project.default_settings
import *" and then customize stuff as needed (eg: INSTALLED_APPS +=
('debug_toolbar',)). This way all the settings files are clearly separated
and stay readable. Might not be best practices but that's how it works
quite well for me.
Cheers,
Florian
--
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/-/13cCcVbWiYwJ.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Florian Apolloner
2013-01-02 22:20:39 UTC
Permalink
Hi Ted,
Post by ted
Florian, the method you use for environment specific settings is one of
the two most common I saw in my survey: local_settings.py being the most
common. Again, best practice vs common practice I don't know.
In my surveys it turned out to be this: people often use local_settings but
once I showed them the benefits of "my" approach they quickly converted.

But again, I'm not proposing my settings.py file as the default, just
Post by ted
provided for context.
Oh, I misunderstood you there. Sorry!

Regards,
Florian
--
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/-/C_qjTbsIFTMJ.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Luciano Pacheco
2013-01-03 01:58:44 UTC
Permalink
Post by Florian Apolloner
* local_settings is imo a bad pattern as they can't easily override
anything without copying it completely into the local_settings (think of
all the settings which are dicts like DATABASES and CACHES)
I use this way to allow variable changes:

try:
execfile('local_settings.py', globals(), locals())
except IOError:
pass

Mostly because I want in development: new apps, middlewares, so these are
possible:

INSTALLED_APPS += ('debug_toolbar', 'django_extensions', 'devserver')
MIDDLEWARE_CLASSES += ('debug_toolbar.middleware.DebugToolbarMiddleware',)

On the main topic, I'm in favor of PROJECT_ROOT settings, it's a common
practice, and isn't that bad, once in production it can be a mount point or
overwritten on local_settings.py

[],
--
Luciano Pacheco
blog.lucmult.com.br
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Luke Plant
2013-01-02 23:12:02 UTC
Permalink
Post by Aymeric Augustin
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.)
Static files are collected from the apps into STATIC_ROOT that is
then served by the web server. To avoid accidentally leaking Python
code over the web, it's a good idea to keep this directory outside of
your source tree.
Media files are written by the application server into MEDIA_ROOT.
It's a good idea to put them on a separate partition (DoS by filling
up / isn't fun), or at least in a directory outside of your source
tree, which must be read-only for the web server.
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.
You are assuming here that use of relative paths and PROJECT_ROOT for
media implies that you are putting your MEDIA_ROOT/STATIC_ROOT *inside*
PROJECT_ROOT. But you don't have to.

I often have the situation where I have multiple copies of a project on
a machine - often 'staging' and 'production' on the same machine (e.g.
shared hosting), and also for other reasons. I have a layout something
like:


/home
/myuser
/apps
/foo_staging
/src
/static
/media
/foo_production
/src
/media
/static

/src is PROJECT_ROOT, and STATIC_ROOT and MEDIA_ROOT will be calculated
relative to that. This system makes projects completely relocatable, and
is a good use case for PROJECT_ROOT IMO.

However, this isn't something that you could put into a default
settings.py, because it assumes things about directory structure outside
the project sources.

Common opinion amongst core devs seems to be against PROJECT_ROOT. If we
are consistent about that, we ought to be thinking about deprecating
TEMPLATE_DIRS, STATICFILES_DIRS,
django.template.loaders.filesystem.Loader,
django.contrib.staticfiles.finders.FileSystemFinder
etc., as mentioned by Shai.


Luke
--
A mosquito cried out in pain:
"A chemist has poisoned my brain!"
The cause of his sorrow
was para-dichloro-
diphenyltrichloroethane

Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Daniel Sokolowski
2013-01-02 14:32:37 UTC
Permalink
+1 on the idea of just adding PROJECT_ROOT official setting and using that
as needed - this is what I do in my projects already.

-----Original Message-----
From: Luke Plant
Sent: Sunday, December 30, 2012 6:01 PM
To: django-developers-/***@public.gmane.org
Subject: Re: Relative path support for TEMPLATE_DIRS and others in
settings.py (django ticket 694)
Post by Cal Leeming [Simplicity Media Ltd]
Could we not have something like this in the settings.py, which in turn
enabled the code pasted above?
TEMPLATE_PATH_RELATIVE=True
For consistency, we'd need STATICFILES_PATH_RELATIVE,
STATIC_ROOT_PATH_RELATIVE, MEDIA_ROOT_PATH_RELATIVE etc. which is
craziness. Having just one extra setting is a big deal.

There are use cases for all of these being absolute paths (or at least
some of them), and use cases for all of them being relative. We've
already chosen absolute paths, and you can generate absolute from
relative using os.path.realpath etc.

The only option I can is whether we put that snippet of code (e.g.
PROJECT_ROOT=os.path.realpath(os.path.dirname(__file__)) ) into the
settings file generated when starting a new project.

Luke
--
"If we could just get everyone to close their eyes and visualise
world peace for an hour, imagine how serene and quiet it would be
until the looting started" -- Anon

Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to
django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.


Daniel Sokolowski
http://klinsight.com/
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to django-developers+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Continue reading on narkive:
Loading...