Absolute paths in settings.py

[Ole Laursen]

Hi,

There are a couple of things in settings.py that require an absolute
path. I don't know about you, but I tend to put all things related to
a project in subdirectories under the project directory. Thus all the
absolute paths have the same prefix, the project directory. Rather
than going trough the hassle of maintaining this by hand, I have begun
using the following snippet:

PROJECT_DIR = os.path.abspath(os.path.dirname(__file__))

then for instance

MEDIA_ROOT = os.path.join(PROJECT_DIR, 'media')

and

TEMPLATE_DIRS = (
# Always use forward slashes, even on Windows.
os.path.join(PROJECT_DIR, 'templates/'),
)

Would it make sense to put this or something like it in Django?


Ole

[matt westerburg]

I would like to see this, it seems to be an idiom that most people use.  I know i have to implementent that exact same thing for every project I have ever done with django.

[Valts Mazurs]

It would be useful to have at least this one by default:
PROJECT_DIR = os.path.abspath(os.path. dirname(__file__))

Other defaults such as MEDIA_ROOT and TEMPLATE_DIRS also would be useful for me as I repeat these exact lines for every project.

Regards,
Valts.

[Thomas K. Adamcik]

On Thu, Oct 30, 2008 at 10:06:17PM +0200, Valts Mazurs wrote:
> It would be useful to have at least this one by default:
> PROJECT_DIR = os.path.abspath(os.path. dirname(__file__))

If django where to ship something like this __file__ would point to somewhere
within the installation folder of django, which is obviously not what we want.

For this to even be considered (IMO) someone would have to present a workaround
for this issue first :)

--
Thomas Kongevold Adamcik

[Rob Hudson]

On 10/30/08, Thomas K. Adamcik <tada...@gmail.com> wrote:
> If django where to ship something like this __file__ would point to somewhere
> within the installation folder of django, which is obviously not what we want.

Not necessarily true. If this code were in the settings.py from the
project_template it would get laid down in your project when you ran
django-admin.py startproject, which is, I think, the appropriate place
for this relative path stuff to land.

See: http://code.djangoproject.com/browser/django/trunk/django/conf/project_template/settings.py

+1 from me. :)

-Rob

[James Bennett]

On Thu, Oct 30, 2008 at 3:20 PM, Rob Hudson <trebor...@gmail.com> wrote:
> Not necessarily true. If this code were in the settings.py from the
> project_template it would get laid down in your project when you ran
> django-admin.py startproject, which is, I think, the appropriate place
> for this relative path stuff to land.

Except for the part where it breaks/causes headaches for eggs and
zipped packages, both of which are somewhat popular in this Python
world.

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

[Valts Mazurs]

On Thu, Oct 30, 2008 at 10:23 PM, James Bennett <ubern...@gmail.com> wrote:

Except for the part where it breaks/causes headaches for eggs and
zipped packages, both of which are somewhat popular in this Python
world.

There should be significantly greater number of Django projects that are deployed without any fancy stuff involved.
Anyway, if someone wants to deploy his project as egg it would be easy to just change "PROJECT_DIR =.." as all other settings might stay the same.

Valts.

[Ole Laursen]

On 30 Okt., 22:55, "Valts Mazurs" <vald...@gmail.com> wrote:
> There should be significantly greater number of Django projects that are
> deployed without any fancy stuff involved.
> Anyway, if someone wants to deploy his project as egg it would be easy to
> just change "PROJECT_DIR =.." as all other settings might stay the same.

Yeah, even without project dir auto-detection, it's better to
construct the absolute paths by concatenating with a PROJECT_DIR if
things are organized that way, DRY. Maybe it's plain, but the idea
didn't occur in my mind until recently. :)

The __file__ trick is a bit of a hack, I suppose Django usually has
some kind of idea of where things are located (or maybe not?).


Ole