#16504 closed New feature (wontfix)
PROJECT_ROOT ought to be in the generated project settings module
Reported by: | Daniel Greenfeld | Owned by: | rvanhoepen |
---|---|---|---|
Component: | Core (Other) | Version: | 1.3 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Design decision needed | |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | yes | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
I see this used by a lot of people in a lot of projects. For experience developers they figure it out on their own. Beginning developers often miss it and hard code all their paths. This becomes a problem on deployment.
import os.path PROJECT_ROOT = os.path.abspath(os.path.dirname(__file__))
Possible alternative solution: Add this to an as-of-yet Django best practices page.
Attachments (1)
Change History (11)
comment:1 by , 13 years ago
Summary: | PROJECT_ROOT ought to be a built-in django settings ref → PROJECT_ROOT ought to be in the generated project settings module |
---|---|
Triage Stage: | Unreviewed → Design decision needed |
comment:2 by , 13 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 13 years ago
Has patch: | set |
---|---|
Needs documentation: | set |
Needs tests: | set |
Triage Stage: | Design decision needed → Ready for checkin |
comment:4 by , 13 years ago
Patch needs improvement: | set |
---|---|
Triage Stage: | Ready for checkin → Design decision needed |
Sorry to slow down your enthusiasm, but:
- design decision needed means a core developer must accept or reject the idea; only a core developer can move a ticket from DDN to Accepted,
- the patch must be reviewed by someone else before it can be marked as ready for checkin,
- the patch can't be ready for checkin if it needs docs and tests.
See https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/ for more information about this process.
Regarding the patch itself:
- You inserted an import between a comment and the line that is commented, so the comment no longer makes sense,
- I don't understand why you set
PROJECT_PATH
todjango/conf
by default.
comment:5 by , 13 years ago
Mmm... I understand... Sorry, I'm new to all of this :)
EDIT:
Updated to take PROJECT_ROOT out of django/conf/global_settings.py,
and uncommented it in django/conf/project_template/settings.py
by , 13 years ago
Attachment: | add_project_root_to_settings.diff added |
---|
comment:6 by , 13 years ago
With this addition, we could provide more sensible defaults: MEDIA_ROOT = os.path.join(PROJECT_ROOT, 'media')
and STATIC_ROOT = os.path.join(PROJECT_ROOT, 'static')
.
This would have prevented #16703.
comment:7 by , 13 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
FTR, this has been proposed before and proven to be counter-productive. The "project" metaphor is only temporary and shouldn't be fortified in yet another setting.
comment:9 by , 11 years ago
I came here following https://code.djangoproject.com/ticket/19410, which is about an absolute path in the tutorial in the sqlite db filename.
I'm new to all of this and no where near design decisions.
But I would like to make a point that in the case of sqlite, relative url is very comfortable.
Thanks,
Shahar
comment:10 by , 11 years ago
The latest iteration of the default settings file created by startproject
includes BASE_DIR, which is essentially the same as PROJECT_DIR, except the name is semantically correct.
Minor irony here, this is an incorrect example: you want to ensure you
abspath
before youdirname
.This could potentially just be a documentation note rather than part of the default generated settings module.
Perhaps you could bring this up on django-dev, Danny?