Shulou(Shulou.com)06/01 Report--

Django project directory structure

Now that you've configured your Heroku account and created your first Heroku application, let's discuss a very important (though often overlooked) topic: Django engineering structure management.

Overview

Most Django projects are very messy. Unfortunately, the default Django project layout does not help. It is too simple to manage the project, which leads to a lot of maintainability problems when dealing with large projects.

This article will help you to have a reasonable layout of your project. Committed to:

Follow best practices

Make your project as intuitive as possible-you (as a developer) can immediately recognize the role of each part of the code

Keep your project standardized as more and more applications are used in your project.

Make it more convenient for your project to deploy in different environments

Make other programmers like your code

Concrete steps

I will start a new project with you in this part. In the process, you need to adjust your project directory structure to the layout described below.

This article describes best practices for highly maintainable structured Django project layouts.

Foundation-default Django project

Before going any further, let's create a new Django project (project)

$django-admin.py startproject djanolicious$cd djangolicious$tree.. ├── djangolicious │ ├── _ _ init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py └── manage.py

1 directory, 5 files

Under the root directory djangolicious, you can get:

Project directory: djangolicious

Manage.py scripts: for managing Django sites

The project directory djangolicious contains:

Settings.py: contains all configuration parameters for the project

Urls.py: URL root configuration

Wsgi.py: WSGI application configuration with built-in runserver command

_ _ init__.py: used to tell python that the current directory is the python module

Manage project requirements description

First, let's create a new file in the project: requirements.txt. Each Django project should have a top-level requirements.txt file that lists all the python packages used in the project.

Note: if you are not familiar with requirements files, you can read the Heroku guidelines to manage python requirements relationships through pip.

Requirement.txt is similar to the following:

Django==1.6psycopy2==2.4.5South==0.7.3gunicorn==0.14.1nrerelic==1.2.0.246django-cerlery==2.4.2

The requirements file is created so that other developers can quickly install the necessary python dependency packages based on the contents of the file after copying your project code. This way they can easily run your code without having to take pains to guess which version of the project depends on the package.

Now you know why we need to do this, so do it!

The first step is modularization.

Creating a top-level requirement.txt in the project directory is a requirement that must be followed, and this ensures that project dependencies can be easily managed

This means: it is quite possible that the development environment dependency of the project is different from your production environment, so you need to put your development and production environment dependencies into requirement.txt, but this will make it difficult to manage.

Therefore, it is best to distinguish the dependencies and requirements of different environments.

Our approach is as follows (under the project djangolicious root directory):

$lsdjangolicious manage.py$touch requirements.txt$mkdir requirements$touch requirements/ {common.txt,dev.txt,prod.txt,test.txt} $tree.. |-- djangolicious | |-- _ init__.py | |-- settings.py | |-- urls.py | |-- wsgi.py |-- manage.py |-- requirements | |-- common.txt | |-- dev.txt | |-- prod.txt | |-- test.txt |-- requirements.txt

2 directories, 10 files

As you can see, I have created a new top-level directory: requirements, which contains a series of requirements documentation for each environment.

If your application only needs to run in the development environment, then only need to be in a dev.txt file. If your application needs to be developed, produced, tested, run in tom and rudy environments-create a .txt file for each of them

Note:common.txt contains descriptions of requirements for sharing in a variety of environments. For example, Django. Django is required in all environments, and you need to use it in both development and production environments.

The purpose of separating the various requirements files is that when, as a programmer, I only need to run the project in the local environment, then I only need to install the software packages mentioned in requirement/dev.txt, but not other packages (production environment, staging, test environment, etc.)

But why am I so concerned about which packages I have to install? Why don't I install them all?

Installing dependency packages takes a long time and can take a lot of time (more than 30 minutes) for large projects.

Many requirements rely on external software or library files to be installed on your local machine to complete the compilation. Avoiding installing library files in this way saves time and unnecessary hassles such as which version of libxml2 and libpq-dev to install.

Lower the threshold for beginners to learn. If your project team has a new development, try to submit the code, it is much easier for him to install a few packages to run the system than to install all the packages.

Step 2-define the requirements document

Now that we understand why we need to modularize the requirements specification document, let's take a look at the details of the requirements specification document in practice.

Below I have listed 4 requirements documents from my actual project, which I will explain in detail.

First, the requirements/common.txt file lists all the basic requirements packages, of which packages are required in any environment (whether it's a development environment, a test environment, a production environment, etc.):

# requirements/common.txtDjango==1.4django-cache-machine==0.6django-celery==2.5.5django-dajaxice==0.2django-guardian==1.0.4django-kombu==0.9.4django-pagination==1.0.7django-sorting==0.1django-tastypie==0.9.11Fabric==1.4.1lxml==2.3.4pyst2==0.4South==0.7.4Sphinx==1.1.3

The following requirements/dev.txt file contains the packages needed by my development environment, which are used only in the development environment.

# requirements/dev.txt-r common.txtdjango-debug-toolbar==0.9.4

In my development environment, I usually use lightweight SQLite3 databases (so I don't need to install any drivers), and the very easy-to-use package django-debug-toolbar allows me to check database queries and performance issues, and so on.

You may wonder what the first line of the file does,'- r common.txt' tells pip to introduce all the generic dependency packages attached to the following list.

This will allow me to run pip intal-r requirements/dev.txt directly from the command line to install all dependent packages required by the development environment:

$pip install-r requirements/dev.txtDownloading/unpacking Django==1.4 (from-r requirements/common.txt (line 1)) Downloading Django-1.4.tar.gz (7.6Mb): 7.6Mb downloaded Running setup.py egg_info for package Django Downloading/unpacking django-cache-machine==0.6 (from-r requirements/common.txt (line 2)) Downloading django-cache-machine-0.6.tar.gz Running setup.py egg_info for package django-cache-machine. Snipped for brevity...

As can be seen from the above running results, it is very useful! When we use pip to install the package in requirements/dev.txt, it not only successfully installs the dependent packages needed in the development environment, but also installs all the packages listed in common.txt! Very beautiful!

The following is a simple requirements/pord.txt requirements statement. It contains the dependency packages for all production environments and the basic dependency packages:

# requirements/prod.txt-r common.txtboto==2.1.1cssmin==0.1.4django-compressor==1.1.2django-htmlmin==0.5.1django-pylibmc-sasl==0.2.4django-storages==1.1.3gunicorn==0.14.1newrelic==1.2.0.246psycopg2==2.4.5pylibmc==1.2.2raven==1.3.5slimit==0.6

Finally, this is an older requirements/test.txt file that lists the dependent packages in the test environment. These packages are used in the unit testing part of the project.

# requirements/test.txt-r common.txtdjango-coverage==1.2.2django-nose==0.1.3mock==0.8.0nosexcover==1.0.7

When I need to run my code in the local development environment, I install the dependency package in requirements/dev.txt

When I run my code in a production environment, I install the dependency packages in requirements/prod.txt

When I want to do some tests on my code, I install the dependency packages in requirements/test.txt

The point is to split your project dependency files according to the following principles:

Simple

Efficient

Intuitive

Step 3-Heroku Best practices

Now, we have modularized our requirements documentation. I bet you are wondering: why is there a requirement.txt file in the root of the project?

The reasons are as follows:

Standardization requires the existence of requirements.txt files

Heroku automatically reads the requirements.txt file in your root directory when you deploy the project and installs these requirements packages.

Heroku installs all the packages you define in requirements.txt, and you have a variety of options:

Let Heroku install all dependent packages: comon.txt,dev.txt,prod.txt, etc.

Let Heroku install only the packages he needs.

We use Heroku to deploy our site, so it's best to have Heroku install only the necessary packages.

Because Heroku has less work to do, this will make our deployed project faster.

Open the requirements.txt file in the root directory and enter the following:

# Install all of our production dependencies only.-r requirements/prod.txt

In this way, Heroku will install our requirements to install the required packages.

Separate application and library files

The next job of managing the Django project is to separate your application from the library.

It is well known that each Django project includes a series of applications. Some applications include models, views, and so on. There are also auxiliary applications.

Typically, these assistive applications are used to customize templatetag, manage commands, and other code. Please don't put these into other apps.

Fortunately, there is an easy way to build a Django project:

Developers can easily find your django application

Developers can easily find your django library files

Do not include a large number of custom applications in your project directory, do not confuse the results of your directory, and it is difficult to find what you want

I create two directories under the home directory of each Django project: apps and libs to store application and library files respectively.

Let's take a look at our example project: djangolicious, what I do is as follows:

$mkdir djangolicious/apps$ mkdir djangolicious/libs$ touch djangolicious/apps/__init__.py$ touch djangolicious/libs/__init__.py$ tree.. ├── djangolicious │ ├── apps │ │ └── _ _ init__.py │ ├── _ _ init__.py │ ├── libs │ │ └── _ _ init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── manage.py ├── requirements │ ├── common.txt │ ├── dev.txt │ ├── prod.txt │ └── test.txt └── requirements.txt

4 directories, 12 files

As shown above, my djangolicious project includes the new apps directory and the libs directory. All that's left is to move the Django application and library to the right location.

In the case of djangolicious, I created some django applications and libraries, and now it's time to move the django application to the right place.

$cd djangolicious/apps$ django-admin.py startapp blog$ django-admin.py startapp reader$ django-admin.py startapp news$ cd.. / libs$ django-admin.py startapp management$ django-admin.py startapp display$ cd.. /.. $tree.. ├── djangolicious │ ├── apps │ │ ├── ├── _ _ init__.py │ ├── models.py │ ├── tests.py │ └── views.py │ │ ├── _ _ init__.py │ │ ├── news │ ├── _ _ init__.py │ ├── models.py │ ├── tests.py │ └── views.py │ │ ── reader │ │ ├── _ _ init__.py │ │ ├── models.py │ │ ├── tests.py │ │ └── views.py │ ├── _ _ init__.py │ ├── libs │ │ display _ _ init__.py │ ├── models.py │ ├── tests.py │ └── views.py │ │ ├── _ _ init__.py │ │ └── management │ │ ├── _ _ init__.py │ │ ├── models.py │ tests.py └── views.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── manage.py ├── requirements │ ├── common.txt │ ├── dev.txt │ ├── prod.txt │ └── test.txt └── requirements.txt

9 directories, 32 files

Now our project has a practical structure! Django applications and library files have been clearly separated. This not only makes it easy to find the desired application or library, but also the directory structure is very clear.

After moving the application and library files, you also need to update your introduction path. If that's what you wrote before:

# blog/views.pyfrom djangolicious.news.models import Newspaperfrom djangolicious.display.templatetags import top_stories

Then you need to change it to:

# blog/views.pyfrom djangolicious.apps.news.models import Newspaperfrom djangolicious.libs.display.templatetags import top_stories

Although the import statement has become longer, I find it very helpful for me as a developer to find the app and librarie that I have introduced that need to be modified.

You also need to update your settings file to include the path to the new application:

# settings.pyINSTALLED_APPS = (... 'djangolicious.apps.blog',' djangolicious.apps.news', 'djangolicious.apps.reader',.)

Build a perfect Django settings module

Building a perfect Django settings module is considered a must-kill for Django development. Every developer has his own idea and may argue about it.

However, what many people do is really very wrong.

Here, I show you the right way to build the perfect Django settings module, regardless of the size of your project, requirements, and other factors.

The settings module we created:

Allows you to easily separate Django environments (development, production, testing, etc.).

Allows you to keep all configuration information under version control.

Allows you to separate passwords and other certificates from the base code through environment variables.

So that you can easily modify the configuration.

The first step-modularization, modularization, modularization

Just as we dealt with requirements documentation in the previous section, configuration information needs to be modular!

First, let's get rid of the pesky default settings.py and instead create a better directory structure:

$rm djangolicious/settings.py$ mkdir djangolicious/settings$ touch djangolicious/settings/ {_ _ init__.py,common.py,dev.py,prod.py Test.py} $tree.. ├── djangolicious │ ├── apps │ │ ├── blog │ ├── _ _ init__.py │ ├── models.py │ ├── tests.py │ └── views.py │ │ ├── _ _ init__.py │ │ News │ ├── _ _ init__.py │ ├── models.py │ ├── tests.py │ └── views.py │ │ └── reader │ │ ├── _ _ init__.py │ │ ├── models.py │ │ Tests.py │ │ └── views.py │ ├── _ _ init__.py │ ├── libs │ │ ├── display │ ├── _ _ init__.py │ ├── models.py │ ├── tests.py │ └── views.py │ ── _ _ init__.py │ │ └── management │ │ ├── _ _ init__.py │ │ ├── models.py │ │ ├── tests.py │ │ └── views.py │ ├── settings │ common.py dev.py ─ _ _ init__.py │ │ ├── prod.py │ │ └── test.py │ ├── urls.py │ └── wsgi.py ├── manage.py ├── requirements │ ├── common.txt │ ├── dev.txt │ ├── prod.txt test.txt requirements.txt

Like the requirements documentation, the settings module should have one configuration file (dev.py,prod.py,test.py) for each environment and one file (common.py) that is shared by various environments.

Resources

Strictly speaking, managing Django projects requires a lot of technology.

However, I don't have many good books or materials to recommend to you.

To better maintain and manage projects, you need to create a lot of projects and constantly improve your code

Other resources:

Translator's note: finally finished the translation, there is basically no problem in the content, will not affect the reader's understanding, but the use of words is not very good, still hope to understand

TOPIC

Celery error AttributeError: 'module' object has no attribute' commit_manually'

Django initialization data django1.7 fixtures initial_data

Problems with windows installation fabric

Tornado template escapes echarts highcharts

Notepad++ runs the python program

Python urlencode

Python acquires the ip address of the system

External python scripts call methods, models, etc. (setup_environ) in the django project

Python reads messages and downloads attachments

How many weeks of python query and the start date of the query week

Python list to duplicate records

Django ORM implements group_by query of native sql

Django database synchronization south usage

Quickly locate large files in linux system

Python xlrd handles excel files

Using django to realize Workflow

The display problem of select drop-down box in Django template

Remote Linux:VNC configuration and modification

JS dynamically controls the hiding or display of elements in HTML

Get the current date is the least week of this year

The Django form select tag appears "-"

Use ueditor to dynamically set read-only properties in Django form

Django inserts data in bulk into the database bulk_create ()

Django login access restrictions @ login_required

Django Model choice

The difference between * args and * * args in Python

Django gets the value of the checkbox check box (reprinted)

The problem of mutual import of views under different app of Django

Get field name, field verbosename, field type in Django model

Django1.6 Custom User Model

Implementing incremental backup of database with python

Python time processing

Python processing JSON data

Django model many-to-many field query

Common basic operations of MySQL

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.