lucianu / django-startproject Goto Github PK

No longer maintained. Instead, try https://github.com/LucianU/bud, which uses Vagrant + Ansible to automate a lot more things.

Python 82.90% Nginx 11.75% HTML 5.34%

django-startproject's Introduction

DEPRECATED in favor of https://github.com/LucianU/bud.

Quickstart

Create your virtualenv with the same name as the project, activate it and install Django.

Create your project by running:

django-admin.py startproject -e py -e conf -e ini -e nginx --template=https://github.com/LucianU/django-startproject/zipball/master <project>

replacing <project> with the name of your project.

Install the requirements in the virtualenv:

cd /path/to/project
pip install -r requirements/common.pip

Create a database and put the credentials in your settings/local.py file.
Sync the database:
```
python manage.py syncdb
```
Run the server and visit the site in the browser. You should see the welcome message from Django:
```
python manage.py runserver 127.0.0.1:8000
```

Finally, you can look at the different files in the confs directory and its subdirectories and adjust the values as you wish. Replace the placeholders with your wanted values. Also, go into the fabfile/targets.py file and adjust the env vars as you see fit.

Overview

This project template is based on a certain stack of applications. These are:

- pip as package manager
- virtualenv and virtualenvwrapper for dependency containment
- postgresql as a database
- nginx and uwsgi as a proxy and application server respectively
- supervisor for process management
- memcached for caching
- fabric + git for deployment

The fabfile package contains several modules that provide tasks for deployment, project setup and interaction with the applications used.

The most basic idea is that when you run a task you have to specify the deployment enviroment on which you want the task to run. To do that you use a task specific to that environment, one of here, stag and prod. here corresponds to your local machine, stag to the staging environment and prod to the production environment. For example, to setup the project on your machine, you run:

fab here first_deploy

This task clones the project in the current directory, creates a virtualenv, installs all the requirements, synchronizes the database and collects the static files, so make sure you've installed the big dependencies, setup the database and populated the local.py settings file with the credentials.

After that, every time you want to deploy changes to production, make sure you've pushed them to the central repo and then run:

fab prod deploy

This task updates the code and checks out the right branch, makes sure all requirements are installed, runs syncdb and collectstatic and then restarts supervisord.

Contribute

If you think this document could be improved in any way, please open an issue on GitHub. The same is true for the project itself.

django-startproject's People

Contributors

Stargazers

Watchers

django-startproject's Issues

Introduce a configuration management tool

There are plenty of options here like Chef and Puppet but also Salt and Ansible, which are written in Python. I've only looked at Ansible so far and it looks appealing, but I also want to learn more about Chef, because vagrant works with it.

In any case, the goal is to be able to deploy the project to a fresh OS install with a single command.

Update README

At the moment, the README is identical to the one from the original django-startproject. Since this fork has changed quite a few things, the README should talk about these new features.

Improve the organization of the fabfile

There's a lot that can be improved about the fabfile. First, I have the tendency to turn into a package with modules for the different types of tasks. Especially tasks handling a specific component, like the server or celery, could be put into different modules.
Also, a task or utility to deal with supervisor remotely could be very handy.

Have different server configuration files for each environment

It would be ideal to have separate configuration files for development, production and maybe staging and also to implement an automatic way of specifying which files to use. Most likely this would be done when the project is deployed.

Move psychopg from common.pip to production.pip

Sometimes I want to develop against sqlite on a machine without postgres installed. Moving psychopg from requirements/common.pip >> production.pip means I don't have to compile against psql-devel.

Change the way the project package and the apps are put into the Python path

The current method to make the project and the apps available for import is to use .pth files written in the site-packages directory of the virtualenv. However, since the goal is to have development and production environments as similar as possible, and the most frequent method that I've seen in production is to use sys.path.append.