We recommend that your development and production environments all use a similar directory layout. This standardization will prove helpful when you have to perform maintenance operations, and it will also ease your day to day work.
This recipe creates a directory structure that groups files having similar life cycles or similar purpose together in standardized subdirectories. Feel free to alter this structure to suit your needs, but be sure to have this documented somewhere.
To create the proposed instance layout, you need to perform the following steps:
- Create one directory per instance:
$ mkdir ~/odoo-dev/projectname $ cd ~/odoo-dev/projectname
- Create a Python
virtualenvin a subdirectory calledenv/:$ virtualenv env - Create some subdirectories, as follows:
$ mkdir src local bin filestore logsThe functions of the subdirectories are as follows:
src/: This contains the clone of Odoo itself and of the various third-party addons projects (see step 4 in this recipe)local/: This is used to save your instance-specific addonsbin/: This includes various helper executable shell scriptsfilestore/: This is used as a file storelogs/(optional): This is used to store the server log files
- Clone Odoo and install the requirements (see Chapter 1, Installing the Odoo Development Environment, for details):
$ git clone https://github.com/odoo/odoo.git src/odoo $ env/bin/pip -r src/odoo/requirements.txt
- Save the following shell script as
bin/odoo:#!/bin/sh ROOT=$(dirname $0)/.. PYTHON=$ROOT/env/bin/python ODOO = $ROOT/src/odoo/odoo.py PYTHON ODOO -c $ROOT/projectname.cfg "$*" exit $?
- Make the script executable:
$ chmod +x bin/odoo - Generate a configuration file for your instance:
bin/odoo --stop-after-init –-save –-addons-path src/odoo/openerp/addons,src/odoo/addons,local --data-dir filestore
- Add a
.gitignorefile, asking to excludedata/,env/, andsrc/:# dotfiles, with exceptions: .* .gitignore # python compiled files *.py[co] # emacs backup files *~ # not tracked subdirectories /env/ /src/ /filestore/ /logs/
- Create a Git repository for this instance and add the files you've added to Git:
$ git init $ git add . $ git commit -m "initial version of projectname"
We generate a clean directory structure with clearly labeled directories and dedicated roles. Especially, we separate the following:
By having one virtualenv per project, we are sure that the projects' dependencies are not going to interfere with the dependencies of other projects that can be running a different version of Odoo or use different third-party addon modules, which need different versions of Python dependencies. This comes at the cost of a little disk space.
In a similar way, using separate clones of Odoo and third-party addon modules for our different projects, we are able to let each of these evolve independently and only install updates on the instances that need them; hence, reducing the risk of introducing regressions.
The bin/odoo script allows to run the server without having to remember the various paths or activate the virtualenv. It also sets the configuration file for us. You can add additional scripts in there to help you in your day-to-day work, for instance, a script to check out the different third-party projects that you need to run your instance.
Regarding the configuration file, we only show the bare minimum options to set up here, but you obviously can set more, such as the database name, the database filter, or the port on which the project listens. Please refer to Chapter 1, Installing the Odoo Development Environment, for more information on this topic.
Finally, by managing all this in a Git repository, it becomes quite easy to replicate the setup on a different computer and share the development among a team.
Tip
Speedup tip
To ease project creation, you can create a template repository containing the empty structure, and fork that repository for each new project; this will save you from retyping the bin/odoo script and the .gitignore file, and any other template file you need (continuous integration configuration, README.md, ChangeLog, and so on).
If you like this approach, we suggest trying out the buildout recipe in Chapter 16, Server Deployment, which goes one step further in this way by using buildout to create the instance environment.