Creating the module directory and manifest

At this point, we should have the ~/odoo-dev/custom-addons directory prepared to receive our Odoo modules, and properly added to the addons path, so that the Odoo server will be able to find them.

Odoo includes a scaffold command to automatically create a new module directory, with a basic structure already in place. We won't use it here, as we will manually create our module structure. You can learn more about it with the following command:

$ ~/odoo-dev/odoo/odoo-bin scaffold --help

An Odoo addon module is a directory that contains a __manifest__.py descriptor file. It also needs to be Python importable, so it must also have a __init__.py file.

The module's directory name is its technical name. We will use library_app for it. The technical name must be a valid Python identifier—it should begin with a letter and can only contain letters, numbers, and the underscore character.

Perform the following steps to initialize the new module:

1. If using the command line, we can initialize our module directory with an empty __init__.py file in it, with these commands:

$ mkdir -p ~/odoo-dev/custom-addons/library_app 
$ touch ~/odoo-dev/custom-addons/library_app/__init__.py

1. Let's add the manifest file. It should contain only a Python dictionary, with about a dozen possible attributes. Of them, only the name attribute is required, but the description and author attributes are also highly advised. Create the __manifest__.py file, alongside the __init__.py file, with the following content:

{ 
    'name': 'Library Management', 
    'description': 'Manage library book catalogue and lending.', 
    'author': 'Daniel Reis', 
    'depends': ['base'], 
    'application': True, 
} 

The depends attribute can have a list of other modules that are required. Odoo will install them automatically when this module is installed. It's not a mandatory attribute, but it's advised to always have it. If no particular dependencies are needed, we should depend on the core base module.

You should be careful to ensure all dependencies are explicitly set here; otherwise, the module may fail to install in a clean database (due to missing dependencies) or have loading errors if, by chance, the other required modules are loaded afterward.

For our application, we don't need any specific dependencies, so we depend on the base module only.

To be concise, we chose to use only some essential descriptor keys:

• name: A string with the addon module title.
• description: A long text with the description of the features, usually in RST format.
• author: The author's name. It is a string, but can contain a comma-separated list of names.
• depends: A list of the addon modules it depends on. They will be automatically installed before this module is.
• application: A Boolean flag, declaring whether the addon module should be featured as an app in the apps list.

Instead of the description key, we can use a README.rst or README.md file in the module's top directory. If both exist, then the manifest description is used.

In a real-world scenario, we recommend that you also use the additional keys, since they are relevant for the Odoo App Store:

• summary: A string displayed as a subtitle for the module.
• version: By default, 1.0. It should follow versioning rules (see http://semver.org/ for details). It is good practice to use the Odoo version before our module version, for example, 12.0.1.0.
• license: By default considered to be LGPL-3.
• website: A URL to get more information about the module. This can help people find more documentation or the issue-tracker to file bugs and suggestions.
• category: A string with the functional category of the module, which defaults to Uncategorized. A list of existing categories can be found in the security Groups form (at Settings | User | Groups), in the Application field drop-down list.

These other descriptor keys are also available:

• installable: By default, it's True, but can be set to False to disable a module.
• auto_install: If set to True, it will be automatically installed as soon as all its dependencies are already installed. It is used for glue modules, which connect two features together as soon as both are installed on the same instance.