The old accepted answer for Django project layout specifies that it's good practice to make a glue application that ties in data from various other applications (e.g. for the home page).
Now that Django 1.4 automatically creates the ../project_name/project_name/ folder, should I use the project_name application as the glue application? Or should I still make a core app and leave the automatically created project_name application alone?
Over the last couple of projects, I've found the following layout to work quite well:
The common folder above contains all the stuff that doesn't really fit elsewhere, including the base urls.py, sitemaps.py, general template tags, general context processors and so on. I find this pretty clean and easy to maintain. Most importantly, the entire directory can be easily checked into git.
I wouldn't worry about the default layout for 1.4. Do whatever suits you.
- apps/
- /foo_app
- /bar_app
- common # The equivalent of the glue app you talk about
- confs # Uwsgi/supervisor/nginx/gunicorn etc. configurations
- /production
- /staging
- /dev
- docs
- fixtures
- media
- static
- requirements # for `pip freeze > ...`
- /production
- /staging
- /development
- scripts
- settings
- private.py # Secret Key etc., not put on VCS
- database.py # DB Settings, also no in VCS
- development.py
- production.py
- staging.py
- default.py # All Django's settings
- custom.py # Custom application settings
- templates
Related
The default folder structure of a project in Django is something like:
myproject/
- myapp/
- models.py
- myproject/
- settings.p
Would it be possible to change that structure?
I'd like to do something like:
myproject/
- myapp/
- infrastructure/
- models.py
- myproject/
- settings.py
or
myproject/
- myapp/
- infrastructure/
- models/
- __init__.py
- some_model.py
- myproject/
- settings.py
I know I can make a models package and split the models into different files. But I'm looking to change also the name/path of that package.
Yes and no. In that case, your app will be myapp.infrastructure and it will need to be added to INSTALLED_APPS in settings.
Having models.py file and models/ folder is mostly same for python. In this case, you will need to import different models in the __init__.py file inside the models/ folder.
The idea is that somehow your models and other codes should be imported somewhere in the project for django management command to see them (ex: for preparing database migrations - makemigrations command). So as long as makemigrations can see your model, you can place them anywhere. It is just a python's way, not directly related to django framework.
As for the name of basic things (models, views, apps, signals, admin and etc.) - I think the only one required to be in its name is models. As it is used directly by its name in ORM. Check this: Django Applications Documentation
So, it is possible thanks to python's syntax, but it is not recommended by django. Django's design practices were created to make it easier for everyone to write a readable app where you can easily understand where things supposed to be and work easily without learning internal rules of the project that someone else designed. It is very important for project where there are many developers and new members can join any time after the project's start. So, unless you are well aware what you are doing, you are free to develop any custom design you want - after all, all you need is for python to be able to import your functions and classes in other parts of the project.
The problem is django server is restarting when I change the settings.py, that does not belong to my django project.
Here is the folder structure.
- project
- django-conf
- settings.py
- urls.py
- ...
- apps
- apps1
- ...
- scrapy-setting
- settings.py <------- file to be updated
When I update the scrapy-setting/settings.py django server will reload.
I don't know why.
In my django config, there is no relation to that folder.
You have three options:
Use noreload flag. BUT this will prevent reload for the whole app.
A monkey patch over the autoreload module, obviously not recommended.
Move the external code out of the Django project
I have looked everywhere and all I could find was outdated or bits and pieces from several different sources, but none of them had a complete step of how to deploy Django to a production environment.
What I would like to see is the recommended way to deploy Django utilizing git, local and production settings.py, .gitignore specifically for Django.
How would I implement the settings to accommodate both environments and what should be added to the .gitignore file so that only necessary files are sent to the git repository?
Please note that I want to know best practices and up to date methods of using local and production settings.
Such questions arise when deploying Django apps.
Where should the settings be stored?
How can I properly implement the settings to accommodate both environments?
What sensitive information should be separate from the main settings?
Update 25/09/2016:
Thanks andreas for clarifying this and now I completely agree that there is no standard way of deploying Django. I went on a long research and found the most common used methods to deploy Django settings. I will share my findings with everyone who's having the same doubt.
Answering
Where should the settings be stored?
The settings are better accommodated within a settings module rather than a single settings.py file.
How can I properly implement the settings to accommodate both environments?
This is where the settings module comes in very handy because you can simply have environment independent settings and they are maintainable with git or any other version control.
What sensitive information should be separate from the main settings?
Sensitive information such as database, email, secret key and anything with authentication related information and as to how you will serve this private information secretly, I do recommend to use andreas suggestion.
You could either create a separate file at /etc/app_settings and make it very restrict or simply use environment variables from within the system.
.gitignore part
For the .gitignore part I found an awesome repo where you can get all sort of examples at https://github.com/github/gitignore.
I ended up using:
# OSX Finder turds
.DS_Store
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class
# Distribution / packaging
.Python
env/
# PyInstaller
# Usually these files are written by a python script from a template
# before PyInstaller builds the exe, so as to inject date/other infos into it.
*.manifest
*.spec
# Installer logs
pip-log.txt
pip-delete-this-directory.txt
# Django stuff:
*.log
my_app/settings/dev.py
bower_components
Because the answer ended up being so long I've created an article explaining every step of the way at Django Settings Deployment.
There is not one recommended way of deploying a Django app. The official documentation provides a guide for deploying with Apache and mod_wsgi. Some other options are a PaaS like Heroku/Dokku or deployment with Docker
It's common to divide your settings in different files. You could for example divide settings in four different files:
base file (base.py) - Common settings for all environments (every file below imports from this with from .base import *
development file (development.py) - settings specific for development, (DEBUG = True etc...)
production file (production.py) - settings specific for the production environment. (DEBUG = False, whitenoise configuration etc)
testing file (testing.py)
You can control what settings file is loaded with the environment variable DJANGO_SETTINGS_MODULE
It is also common recommended practice that you store secrets like the SECRET_KEY in environment variables. SECRET_KEY = os.environ.get('SECRET_KEY', None). Or check out the django-environ package.
Check out this repo for an example setup.
My question is simple. Imagine that you have a project built with marionette/backbone and you have two target medias: mobile and desktop. There is a backing server, written in DJango (or Ruby, or etc.).
How can I organize the project, so I can compile it to mobile and make it run for desktop? I mean, imagine collections, that have a url parameter. Set it to relative? To absolute, from scratch?
The project already has a feasible layout where I can compile it using r.js. It's pretty much like this:
repo-root/
- src/
- assets/
- css/
- images/
- project-code/
- vendor/
- build.js
- config.xml (phonegap conf)
- index.html
- main.js
- tests/
- bower.json
- .gitignore
here's an example of a collection:
define(function(require){
"use strict";
var Backbone = require("backbone");
var FeatureClass = require("atlas-backbone/models/FeatureClass");
return Backbone.Collection.extend({
url: "api/featureclasses",
model: FeatureClass
});
});
My question is how to organize this, so it can be compiled to a mobile device and run in a desktop version.
In my current job on my current project we make extensive use of Gulp and gulp tasks. We have Gulp tasks for production and for development, and setup different pipelines for each.
Optionally, if you would like to manage such things independently you can utilize more antiquated methods such as a mock server, relative URLs, or host file changes.
I've problems running the simplest django project within GAE.
After running django-admin startproject myproj (Using django 1.4 from Google SDK), the folder hierarchy look as:
+ myproj (root folder of project)
- manage.py
+ myproj (a sub folder for the project files)
- __init__.py
- settings.py
- urls.py
- wsgi.py
I then add the usual app.yaml to the root folder - that is to the same folder where manage.py is.
application: u-pavarotti
version: 1
runtime: python27
api_version: 1
threadsafe: true
libraries:
- name: django
version: "1.4"
builtins:
- django_wsgi: on
syncdb, dbshell, shell ... works great. Even manage.py runserver works file. However, trying to run dev_appserver fails. The exception I get is:
ImportError: Could not import settings 'settings'.
Well, taking a look at google/appengine/ext/django/main (which django_wsgi is basically setting a URL handler for .* to the google.appengine.ext.django.main.app) is appears that it expect to find settings in the python path. But without doing anything, the module to import is myproj.settings (as myproj isn't in the path).
Now, adding .../myproj/myproj (the lower folder) to the PYTHONPATH solve everything on my dev machine, but as I have no control on the search path on the GAE deployment - this solution won't work.
I can move all files, or just settings.py up to the upper myproj, or move app.yaml down (kinda same thing), but it requires various changes form the default genereated settings.py - and I don't this is the way to go. Alternatively, I can write my own handler, which will instantiate django.core.handlers.wsge.WSGIHandler (old tutorials used to do that) - again, seems against the intention of at least the creators of the 'builtin' attribute of app.yaml.
I wonder how everyone else is solving this issue, and what is the right thing to do.
You can declare the environment variable DJANGO_SETTINGS_MODULE in your app.yaml:
env_variables:
DJANGO_SETTINGS_MODULE: 'myproj.settings'