My translations are working locally, but in production at Heroku, my site remains in its default language (English) after changing the language.
These are in my settings.py file:
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
USE_I18N = True
USE_L10N = True
LOCALE_PATHS = [os.path.join(BASE_DIR, 'locale')]
This is my structure:
myproject
├── Procfile
├── locale
│ └── fr
│ └── LC_MESSAGES
│ ├── django.mo
│ └── django.po
├── myproject
│ ├── __init__.py
│ └── settings.py
I thought it was a path issue so I SSH'd into my Heroku app and printed LOCALE_PATHS:
>>> from myproject.settings import LOCALE_PATHS
>>> print(LOCALE_PATHS)
['/app/locale']
And pwd in locale/ returns pwd
/app/locale.
What did I do wrong?
I found the issue:
my django.mo file was ignored by .gitignore as I use the default GitHub Python gitignore file.
The problem is that .mo files (compiled translations) are not present in the repo, and therefore not packaged to be deployed together with the rest of the application during the Heroku build process.
The possible solutions are to:
Add them to the repository
Generate .mo files during the build
I suggest to generate them during the build, for these reasons:
It automates compilation, one less manual step
It will ensure that the translations are always up to date
The compiled files are not source, and therefore should be in the repository
To generate them, you can use the post compile hook of the Heroku build:
Create a file bin/post_compile (no extension, like procfile) with the following line:
python ./manage.py compilemessages
Optionally you can add the specific language (e.g. python ./manage.py compilemessages -l nl)
I got this last part from this answer to a similar question.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I know there is actually no single right way. However I've found that it's hard to create a directory structure that works well and remain clean for every developer and administrator. There is some standard structure in most projects on github. But it does not show a way to organize another files and all projects on pc.
What is the most convenient way to organize all these directories on development machine? How do you name them, and how do you connect and deploy this to server?
projects (all projects that your are working on)
source files (the application itself)
working copy of repository (I use git)
virtual environment (I prefer to place this near the project)
static root (for compiled static files)
media root (for uploaded media files)
README
LICENSE
documents
sketches
examples (an example project that uses the application provided by this project)
database (in case sqlite is used)
anything else that you usually need for successful work on project
The problems that I want to solve:
Good names of directories so that their purpose is clear.
Keeping all project files (including virtualenv) in one place, so I can easily copy, move, archive, remove whole project or estimate disk space usage.
Creating multiple copies of some selected file sets such as entire application, repository or virtualenv, while keeping single copy of another files that I don't want to clone.
Deploying right set of files to the server simply by rsyncing selected one dir.
There're two kind of Django "projects" that I have in my ~/projects/ directory, both have a bit different structure.:
Stand-alone websites
Pluggable applications
Stand-alone website
Mostly private projects, but doesn't have to be. It usually looks like this:
~/projects/project_name/
docs/ # documentation
scripts/
manage.py # installed to PATH via setup.py
project_name/ # project dir (the one which django-admin.py creates)
apps/ # project-specific applications
accounts/ # most frequent app, with custom user model
__init__.py
...
settings/ # settings for different environments, see below
__init__.py
production.py
development.py
...
__init__.py # contains project version
urls.py
wsgi.py
static/ # site-specific static files
templates/ # site-specific templates
tests/ # site-specific tests (mostly in-browser ones)
tmp/ # excluded from git
setup.py
requirements.txt
requirements_dev.txt
pytest.ini
...
Settings
The main settings are production ones. Other files (eg. staging.py,
development.py) simply import everything from production.py and override only necessary variables.
For each environment, there are separate settings files, eg. production,
development. I some projects I have also testing (for test runner), staging
(as a check before final deploy) and heroku (for deploying to heroku) settings.
Requirements
I rather specify requirements in setup.py directly. Only those required for
development/test environment I have in requirements_dev.txt.
Some services (eg. heroku) requires to have requirements.txt in root directory.
setup.py
Useful when deploying project using setuptools. It adds manage.py to PATH, so I can run manage.py directly (anywhere).
Project-specific apps
I used to put these apps into project_name/apps/ directory and import them
using relative imports.
Templates/static/locale/tests files
I put these templates and static files into global templates/static directory, not inside each app.
These files are usually edited by people, who doesn't care about project code
structure or python at all. If you are full-stack developer working alone or
in a small team, you can create per-app templates/static directory. It's really just a matter of taste.
The same applies for locale, although sometimes it's convenient to create separate locale directory.
Tests are usually better to place inside each app, but usually there is many
integration/functional tests which tests more apps working together, so global
tests directory does make sense.
Tmp directory
There is temporary directory in project root, excluded from VCS. It's used to
store media/static files and sqlite database during development. Everything in
tmp could be deleted anytime without any problems.
Virtualenv
I prefer virtualenvwrapper and place all venvs into ~/.venvs directory,
but you could place it inside tmp/ to keep it together.
Project template
I've created project template for this setup, django-start-template
Deployment
Deployment of this project is following:
source $VENV/bin/activate
export DJANGO_SETTINGS_MODULE=project_name.settings.production
git pull
pip install -r requirements.txt
# Update database, static files, locales
manage.py syncdb --noinput
manage.py migrate
manage.py collectstatic --noinput
manage.py makemessages -a
manage.py compilemessages
# restart wsgi
touch project_name/wsgi.py
You can use rsync instead of git, but still you need to run batch of commands to update your environment.
Recently, I made django-deploy app, which allows me to run single management command to update environment, but I've used it for one project only and I'm still experimenting with it.
Sketches and drafts
Draft of templates I place inside global templates/ directory. I guess one can create folder sketches/ in project root, but haven't used it yet.
Pluggable application
These apps are usually prepared to publish as open-source. I've taken example
below from django-forme
~/projects/django-app/
docs/
app/
tests/
example_project/
LICENCE
MANIFEST.in
README.md
setup.py
pytest.ini
tox.ini
.travis.yml
...
Name of directories is clear (I hope). I put test files outside app directory,
but it really doesn't matter. It is important to provide README and setup.py, so package is easily installed through pip.
My answer is inspired on my own working experience, and mostly in the book Two Scoops of Django which I highly recommend, and where you can find a more detailed explanation of everything. I just will answer some of the points, and any improvement or correction will be welcomed. But there also can be more correct manners to achieve the same purpose.
Projects
I have a main folder in my personal directory where I maintain all the projects where I am working on.
Source Files
I personally use the django project root as repository root of my projects. But in the book is recommended to separate both things. I think that this is a better approach, so I hope to start making the change progressively on my projects.
project_repository_folder/
.gitignore
Makefile
LICENSE.rst
docs/
README.rst
requirements.txt
project_folder/
manage.py
media/
app-1/
app-2/
...
app-n/
static/
templates/
project/
__init__.py
settings/
__init__.py
base.py
dev.py
local.py
test.py
production.py
ulrs.py
wsgi.py
Repository
Git or Mercurial seem to be the most popular version control systems among Django developers. And the most popular hosting services for backups GitHub and Bitbucket.
Virtual Environment
I use virtualenv and virtualenvwrapper. After installing the second one, you need to set up your working directory. Mine is on my /home/envs directory, as it is recommended on virtualenvwrapper installation guide. But I don't think the most important thing is where is it placed. The most important thing when working with virtual environments is keeping requirements.txt file up to date.
pip freeze -l > requirements.txt
Static Root
Project folder
Media Root
Project folder
README
Repository root
LICENSE
Repository root
Documents
Repository root. This python packages can help you making easier mantaining your documentation:
reStructuredText
Sphinx
Sketches
Examples
Database
I don't like to create a new settings/ directory. I simply add files named settings_dev.py and settings_production.py so I don't have to edit the BASE_DIR.
The approach below increase the default structure instead of changing it.
mysite/ # Project
conf/
locale/
en_US/
fr_FR/
it_IT/
mysite/
__init__.py
settings.py
settings_dev.py
settings_production.py
urls.py
wsgi.py
static/
admin/
css/ # Custom back end styles
css/ # Project front end styles
fonts/
images/
js/
sass/
staticfiles/
templates/ # Project templates
includes/
footer.html
header.html
index.html
myapp/ # Application
core/
migrations/
__init__.py
templates/ # Application templates
myapp/
index.html
static/
myapp/
js/
css/
images/
__init__.py
admin.py
apps.py
forms.py
models.py
models_foo.py
models_bar.py
views.py
templatetags/ # Application with custom context processors and template tags
__init__.py
context_processors.py
templatetags/
__init__.py
templatetag_extras.py
gulpfile.js
manage.py
requirements.txt
I think this:
settings.py
settings_dev.py
settings_production.py
is better than this:
settings/__init__.py
settings/base.py
settings/dev.py
settings/production.py
This concept applies to other files as well.
I usually place node_modules/ and bower_components/ in the project directory within the default static/ folder.
Sometime a vendor/ directory for Git Submodules but usually I place them in the static/ folder.
As per the Django Project Skeleton, the proper directory structure that could be followed is :
[projectname]/ <- project root
├── [projectname]/ <- Django root
│ ├── __init__.py
│ ├── settings/
│ │ ├── common.py
│ │ ├── development.py
│ │ ├── i18n.py
│ │ ├── __init__.py
│ │ └── production.py
│ ├── urls.py
│ └── wsgi.py
├── apps/
│ └── __init__.py
├── configs/
│ ├── apache2_vhost.sample
│ └── README
├── doc/
│ ├── Makefile
│ └── source/
│ └── *snap*
├── manage.py
├── README.rst
├── run/
│ ├── media/
│ │ └── README
│ ├── README
│ └── static/
│ └── README
├── static/
│ └── README
└── templates/
├── base.html
├── core
│ └── login.html
└── README
Refer https://django-project-skeleton.readthedocs.io/en/latest/structure.html for the latest directory structure.
Here is what I follow on My system.
All Projects: There is a projects directory in my home folder i.e. ~/projects. All the projects rest inside it.
Individual Project: I follow a standardized structure template used by many developers called django-skel for individual projects. It basically takes care of all your static file and media files and all.
Virtual environment: I have a virtualenvs folder inside my home to store all virtual environments in the system i.e. ~/virtualenvs . This gives me flexibility that I know what all virtual environments I have and can look use easily
The above 3 are the main partitions of My working environment.
All the other parts you mentioned are mostly dependent on project to project basis (i.e. you might use different databases for different projects). So they should reside in their individual projects.
You can use https://github.com/Mischback/django-project-skeleton repository.
Run below command:
$ django-admin startproject --template=https://github.com/Mischback/django-project-skeleton/archive/development.zip [projectname]
The structure is something like this:
[projectname]/ <- project root
├── [projectname]/ <- Django root
│ ├── __init__.py
│ ├── settings/
│ │ ├── common.py
│ │ ├── development.py
│ │ ├── i18n.py
│ │ ├── __init__.py
│ │ └── production.py
│ ├── urls.py
│ └── wsgi.py
├── apps/
│ └── __init__.py
├── configs/
│ ├── apache2_vhost.sample
│ └── README
├── doc/
│ ├── Makefile
│ └── source/
│ └── *snap*
├── manage.py
├── README.rst
├── run/
│ ├── media/
│ │ └── README
│ ├── README
│ └── static/
│ └── README
├── static/
│ └── README
└── templates/
├── base.html
├── core
│ └── login.html
└── README
I feel like I must be looking over something obvious because I am having trouble finding anything online about this. But basically here it is, I have a django Project, and I would like to store my apps inside of an apps folder, like thus...
myproject/
client-side/
media/
static/
templates/
apps/
app1/
app2/
etc.
__init__.py
manage.py
etc. (rest of root directory)
but have been unable to figure out how to >>>python manage.py startapp newapp and have it placed into the /apps/ folder. Is it ok to simply ok to startapp at the root level and manually move them into the /apps/ folder?
I greatly appreciate your thoughts and answers.
FYI running python 3.4.2 and Django 1.9.5 on Windows 10
You can specify the app's directory as a second parameter:
python manage.py startapp <app_name> <app_directory>
Note that no directory will be created, the app's files will be created directly in the specified directory. Example:
python manage.py startapp myapp apps/myapp
Will result in the given directory structure:
apps
└── myapp
├── __init__.py
├── admin.py
├── apps.py
├── migrations
│ └── __init__.py
├── models.py
├── tests.py
└── views.py
Also note that the command won't create the directory for you.
Edit: as another (now deleted) answer pointed out, running the command from the apps directory would also work:
cd apps
python ../manage.py startapp myapp
You can also use the django-admin command as well.
cd apps && django-admin startapp app_1
this will work as well
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I know there is actually no single right way. However I've found that it's hard to create a directory structure that works well and remain clean for every developer and administrator. There is some standard structure in most projects on github. But it does not show a way to organize another files and all projects on pc.
What is the most convenient way to organize all these directories on development machine? How do you name them, and how do you connect and deploy this to server?
projects (all projects that your are working on)
source files (the application itself)
working copy of repository (I use git)
virtual environment (I prefer to place this near the project)
static root (for compiled static files)
media root (for uploaded media files)
README
LICENSE
documents
sketches
examples (an example project that uses the application provided by this project)
database (in case sqlite is used)
anything else that you usually need for successful work on project
The problems that I want to solve:
Good names of directories so that their purpose is clear.
Keeping all project files (including virtualenv) in one place, so I can easily copy, move, archive, remove whole project or estimate disk space usage.
Creating multiple copies of some selected file sets such as entire application, repository or virtualenv, while keeping single copy of another files that I don't want to clone.
Deploying right set of files to the server simply by rsyncing selected one dir.
There're two kind of Django "projects" that I have in my ~/projects/ directory, both have a bit different structure.:
Stand-alone websites
Pluggable applications
Stand-alone website
Mostly private projects, but doesn't have to be. It usually looks like this:
~/projects/project_name/
docs/ # documentation
scripts/
manage.py # installed to PATH via setup.py
project_name/ # project dir (the one which django-admin.py creates)
apps/ # project-specific applications
accounts/ # most frequent app, with custom user model
__init__.py
...
settings/ # settings for different environments, see below
__init__.py
production.py
development.py
...
__init__.py # contains project version
urls.py
wsgi.py
static/ # site-specific static files
templates/ # site-specific templates
tests/ # site-specific tests (mostly in-browser ones)
tmp/ # excluded from git
setup.py
requirements.txt
requirements_dev.txt
pytest.ini
...
Settings
The main settings are production ones. Other files (eg. staging.py,
development.py) simply import everything from production.py and override only necessary variables.
For each environment, there are separate settings files, eg. production,
development. I some projects I have also testing (for test runner), staging
(as a check before final deploy) and heroku (for deploying to heroku) settings.
Requirements
I rather specify requirements in setup.py directly. Only those required for
development/test environment I have in requirements_dev.txt.
Some services (eg. heroku) requires to have requirements.txt in root directory.
setup.py
Useful when deploying project using setuptools. It adds manage.py to PATH, so I can run manage.py directly (anywhere).
Project-specific apps
I used to put these apps into project_name/apps/ directory and import them
using relative imports.
Templates/static/locale/tests files
I put these templates and static files into global templates/static directory, not inside each app.
These files are usually edited by people, who doesn't care about project code
structure or python at all. If you are full-stack developer working alone or
in a small team, you can create per-app templates/static directory. It's really just a matter of taste.
The same applies for locale, although sometimes it's convenient to create separate locale directory.
Tests are usually better to place inside each app, but usually there is many
integration/functional tests which tests more apps working together, so global
tests directory does make sense.
Tmp directory
There is temporary directory in project root, excluded from VCS. It's used to
store media/static files and sqlite database during development. Everything in
tmp could be deleted anytime without any problems.
Virtualenv
I prefer virtualenvwrapper and place all venvs into ~/.venvs directory,
but you could place it inside tmp/ to keep it together.
Project template
I've created project template for this setup, django-start-template
Deployment
Deployment of this project is following:
source $VENV/bin/activate
export DJANGO_SETTINGS_MODULE=project_name.settings.production
git pull
pip install -r requirements.txt
# Update database, static files, locales
manage.py syncdb --noinput
manage.py migrate
manage.py collectstatic --noinput
manage.py makemessages -a
manage.py compilemessages
# restart wsgi
touch project_name/wsgi.py
You can use rsync instead of git, but still you need to run batch of commands to update your environment.
Recently, I made django-deploy app, which allows me to run single management command to update environment, but I've used it for one project only and I'm still experimenting with it.
Sketches and drafts
Draft of templates I place inside global templates/ directory. I guess one can create folder sketches/ in project root, but haven't used it yet.
Pluggable application
These apps are usually prepared to publish as open-source. I've taken example
below from django-forme
~/projects/django-app/
docs/
app/
tests/
example_project/
LICENCE
MANIFEST.in
README.md
setup.py
pytest.ini
tox.ini
.travis.yml
...
Name of directories is clear (I hope). I put test files outside app directory,
but it really doesn't matter. It is important to provide README and setup.py, so package is easily installed through pip.
My answer is inspired on my own working experience, and mostly in the book Two Scoops of Django which I highly recommend, and where you can find a more detailed explanation of everything. I just will answer some of the points, and any improvement or correction will be welcomed. But there also can be more correct manners to achieve the same purpose.
Projects
I have a main folder in my personal directory where I maintain all the projects where I am working on.
Source Files
I personally use the django project root as repository root of my projects. But in the book is recommended to separate both things. I think that this is a better approach, so I hope to start making the change progressively on my projects.
project_repository_folder/
.gitignore
Makefile
LICENSE.rst
docs/
README.rst
requirements.txt
project_folder/
manage.py
media/
app-1/
app-2/
...
app-n/
static/
templates/
project/
__init__.py
settings/
__init__.py
base.py
dev.py
local.py
test.py
production.py
ulrs.py
wsgi.py
Repository
Git or Mercurial seem to be the most popular version control systems among Django developers. And the most popular hosting services for backups GitHub and Bitbucket.
Virtual Environment
I use virtualenv and virtualenvwrapper. After installing the second one, you need to set up your working directory. Mine is on my /home/envs directory, as it is recommended on virtualenvwrapper installation guide. But I don't think the most important thing is where is it placed. The most important thing when working with virtual environments is keeping requirements.txt file up to date.
pip freeze -l > requirements.txt
Static Root
Project folder
Media Root
Project folder
README
Repository root
LICENSE
Repository root
Documents
Repository root. This python packages can help you making easier mantaining your documentation:
reStructuredText
Sphinx
Sketches
Examples
Database
I don't like to create a new settings/ directory. I simply add files named settings_dev.py and settings_production.py so I don't have to edit the BASE_DIR.
The approach below increase the default structure instead of changing it.
mysite/ # Project
conf/
locale/
en_US/
fr_FR/
it_IT/
mysite/
__init__.py
settings.py
settings_dev.py
settings_production.py
urls.py
wsgi.py
static/
admin/
css/ # Custom back end styles
css/ # Project front end styles
fonts/
images/
js/
sass/
staticfiles/
templates/ # Project templates
includes/
footer.html
header.html
index.html
myapp/ # Application
core/
migrations/
__init__.py
templates/ # Application templates
myapp/
index.html
static/
myapp/
js/
css/
images/
__init__.py
admin.py
apps.py
forms.py
models.py
models_foo.py
models_bar.py
views.py
templatetags/ # Application with custom context processors and template tags
__init__.py
context_processors.py
templatetags/
__init__.py
templatetag_extras.py
gulpfile.js
manage.py
requirements.txt
I think this:
settings.py
settings_dev.py
settings_production.py
is better than this:
settings/__init__.py
settings/base.py
settings/dev.py
settings/production.py
This concept applies to other files as well.
I usually place node_modules/ and bower_components/ in the project directory within the default static/ folder.
Sometime a vendor/ directory for Git Submodules but usually I place them in the static/ folder.
As per the Django Project Skeleton, the proper directory structure that could be followed is :
[projectname]/ <- project root
├── [projectname]/ <- Django root
│ ├── __init__.py
│ ├── settings/
│ │ ├── common.py
│ │ ├── development.py
│ │ ├── i18n.py
│ │ ├── __init__.py
│ │ └── production.py
│ ├── urls.py
│ └── wsgi.py
├── apps/
│ └── __init__.py
├── configs/
│ ├── apache2_vhost.sample
│ └── README
├── doc/
│ ├── Makefile
│ └── source/
│ └── *snap*
├── manage.py
├── README.rst
├── run/
│ ├── media/
│ │ └── README
│ ├── README
│ └── static/
│ └── README
├── static/
│ └── README
└── templates/
├── base.html
├── core
│ └── login.html
└── README
Refer https://django-project-skeleton.readthedocs.io/en/latest/structure.html for the latest directory structure.
Here is what I follow on My system.
All Projects: There is a projects directory in my home folder i.e. ~/projects. All the projects rest inside it.
Individual Project: I follow a standardized structure template used by many developers called django-skel for individual projects. It basically takes care of all your static file and media files and all.
Virtual environment: I have a virtualenvs folder inside my home to store all virtual environments in the system i.e. ~/virtualenvs . This gives me flexibility that I know what all virtual environments I have and can look use easily
The above 3 are the main partitions of My working environment.
All the other parts you mentioned are mostly dependent on project to project basis (i.e. you might use different databases for different projects). So they should reside in their individual projects.
You can use https://github.com/Mischback/django-project-skeleton repository.
Run below command:
$ django-admin startproject --template=https://github.com/Mischback/django-project-skeleton/archive/development.zip [projectname]
The structure is something like this:
[projectname]/ <- project root
├── [projectname]/ <- Django root
│ ├── __init__.py
│ ├── settings/
│ │ ├── common.py
│ │ ├── development.py
│ │ ├── i18n.py
│ │ ├── __init__.py
│ │ └── production.py
│ ├── urls.py
│ └── wsgi.py
├── apps/
│ └── __init__.py
├── configs/
│ ├── apache2_vhost.sample
│ └── README
├── doc/
│ ├── Makefile
│ └── source/
│ └── *snap*
├── manage.py
├── README.rst
├── run/
│ ├── media/
│ │ └── README
│ ├── README
│ └── static/
│ └── README
├── static/
│ └── README
└── templates/
├── base.html
├── core
│ └── login.html
└── README
I am happily developing a Django project in my own Git repo on my localhost. I am creating branches, committing and merging happily. The path is something like:
/path/to/git/django/
and the structure is:
project
├── README
├── REQUIREMENTS
├── __init__.py
├── fabfile.py
├── app1
├── manage.py
├── app2
├── app3
├── app4
└── project
The rest of my development team still use Subversion, which is one giant repo with multiple projects. When I am working with that on my localhost I am still using Git (via git-svn). The path is something like
/path/to/giant-svn-repo/
Projects live under this like:
giant-svn-repo
|── project1
|── project2
|── project3
└── project4
When I want to work with the latest changes from the remote svn repo I just do a git-svn rebase. Then for new features I create a new branch, develop, commit, checkout master, merge branch with master, delete branch, and then a final git-svn dcommit. Cool. Everything works well.
These two repositories (lets call them git-django and git-svn) are completely independent right now.
Now I want to add git-django into the git-svn repo as a new project (ie. in a child directory called djangoproject). I have this working pretty well, using the following workflow:
cd into git-svn repo
Create a new branch in the git-svn repo
Make a new directory to host my django project
Add a new remote that links to my original Django project
Merge the remote into my local directory
Read-tree with the prefix of relative path djangoproject so it puts the codebase into the correct location based on the root of git-svn repo
Commit the changes so everything gets dumped into the correct place
From the command line this looks like:
> cd /path/to/giant-svn-repo
> git checkout -b my_django_project
> mkdir /path/to/giant-svn-repo/djangoproject
> git remote add -f local_django_dev /path/to/git/django/project
> git merge -s ours --no-commit local_django_dev/master
> git read-tree --prefix=djangoproject -u local_django_dev/master
> git commit -m 'Merged local_django_dev into subdirectory djangoproject'
This works, but in addition to the contents of the django git repo being in /path/to/giant-svn-repo/djangoproject it is also in the main root of the repository tree!
project
├── README
├── REQUIREMENTS
├── __init__.py
├── fabfile.py
├── djangoproject
│ ├── README
│ ├── REQUIREMENTS
│ ├── __init__.py
│ ├── fabfile.py
│ ├── app1
│ ├── manage.py
│ ├── app2
│ ├── app3
│ ├── app4
│ └── project
├── app1
├── manage.py
├── app2
├── app3
├── app4
└── project
I seem to have polluted the parent directory where all the projects of the giant-svn-repo are located.
Is there any way I can stop this happening?
(BTW this has all been done in a test directory structure - I haven't corrupted anything yet. Just trying to figure out the best way to do it)
I am sure it is just (re)defining one more argument to either git merge, git read-tree or git commit but I am pretty much at my limit of git kung-fu.
Thanks in advance.
I am having some trouble setting the DJANGO_SETTINGS_MODULE for my Django project.
I have a directory at ~/dev/django-project. In this directory I have a virtual environment which I have set up with virtualenv, and also a django project called "blossom" with an app within it called "onora". Running tree -L 3 from ~/dev/django-project/ shows me the following:
.
├── Procfile
├── blossom
│ ├── __init__.py
│ ├── __init__.pyc
│ ├── fixtures
│ │ └── initial_data_test.yaml
│ ├── manage.py
│ ├── onora
│ │ ├── __init__.py
│ │ ├── __init__.pyc
│ │ ├── admin.py
│ │ ├── admin.pyc
│ │ ├── models.py
│ │ ├── models.pyc
│ │ ├── tests.py
│ │ └── views.py
│ ├── settings.py
│ ├── settings.pyc
│ ├── sqlite3-database
│ ├── urls.py
│ └── urls.pyc
├── blossom-sqlite3-db2
├── requirements.txt
└── virtual_environment
├── bin
│ ├── activate
│ ├── activate.csh
│ ├── activate.fish
│ ├── activate_this.py
│ ├── django-admin.py
│ ├── easy_install
│ ├── easy_install-2.7
│ ├── gunicorn
│ ├── gunicorn_django
│ ├── gunicorn_paster
│ ├── pip
│ ├── pip-2.7
│ ├── python
│ └── python2.7 -> python
├── include
│ └── python2.7 -> /System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
└── lib
└── python2.7
I am trying to dump my data from the database with the command
django-admin.py dumpdata
My approach is to run cd ~/dev/django-project and then run source virtual_environment/bin/activate and then run django-admin.py dumpdata
However, I am getting the following error:
ImportError: Settings cannot be imported, because environment variable DJANGO_SETTINGS_MODULE is undefined.
I did some googling and found this page: https://docs.djangoproject.com/en/dev/topics/settings/#designating-the-settings
which tell me that
When you use Django, you have to tell it which settings you're using.
Do this by using an environment variable, DJANGO_SETTINGS_MODULE. The
value of DJANGO_SETTINGS_MODULE should be in Python path syntax, e.g.
mysite.settings. Note that the settings module should be on the Python
import search path.
Following a suggestion at Setting DJANGO_SETTINGS_MODULE under virtualenv? I appended the lines
export DJANGO_SETTINGS_MODULE="blossom.settings"
echo $DJANGO_SETTINGS_MODULE
to virtual_environment/bin/activate. Now, when I run the activate command in order to activate the virtual environment, I get output reading:
DJANGO_SETTINGS_MODULE set to blossom.settings
This looks good to me, but now the problem I have is that running
django-admin.py dumpdata
returns the following error:
ImportError: Could not import settings 'blossom.settings' (Is it on sys.path?): No module named blossom.settings
What am I doing wrong? How can I check thesys.path? How is this supposed to work?
Thanks.
Don't run django-admin.py for anything other than the initial project creation. For everything after that, use manage.py, which takes care of the finding the settings.
I just encountered the same error, and eventually managed to work out what was going on (the big clue was (Is it on sys.path?) in the ImportError).
You need add your project directory to PYTHONPATH — this is what the documentation means by
Note that the settings module should be on the Python import search path.
To do so, run
$ export PYTHONPATH=$PYTHONPATH:$PWD
from the ~/dev/django-project directory before you run django-admin.py.
You can add this command (replacing $PWD with the actual path to your project, i.e. ~/dev/django-project) to your virtualenv's source script. If you choose to advance to virtualenvwrapper at some point (which is designed for this kind of situation), you can add the export PY... line to the auto-generated postactivate hook script.
mkdjangovirtualenv automates this even further, adding the appropriate entry to the Python path for you, but I have not tested it myself.
On unix-like machine you can simply alias virtualenv like this and use alias instead of typing everytime:
.bashrc
alias cool='source /path_to_ve/bin/activate; export DJANGO_SETTINGS_MODULE=django_settings_folder.settings; cd path_to_django_project; export PYTHONPATH=$PYTHONPATH:$PWD'
My favourite alternative is passing settings file as runtime parameter to manage.py in a python package syntax, e.g:
python manage.py runserver --settings folder.filename
more info django docs
I know there are plenty answers, but this one worked for me just for the record.
Navigate to your .virtual_env folder where all the virtual environments are.
Go to the environment folder specific to your project
Append export DJANGO_SETTINGS_MODULE=<django_project>.settings
or export DJANGO_SETTINGS_MODULE=<django_project>.settings.local if you are using a separate settings file stored in a settings folder.
Yet another way to do deal with this issue is to use the python dotenv package and include PYTHONPATH and DJANGO_SETTINGS_MODULE in the .env file along with your other environment variables. Then modify your manage.py and wsgi.py to load them as stated in the instructions.
from dotenv import load_dotenv
load_dotenv()
I had similar error while working on windows machine. My problem was using wrong debug configuration. Use Python:django as your debug config option.
First ensure you've exported/set django_settings_module correctly here.