How to Properly Structure Custom Tryton Modules?

Support Developer
1

Hello everyone,

On behalf of my company, I’m developing an ERP based on Tryton to replace our Excel files.
I’m wondering what would be the cleanest way to structure our custom modules. I see two possible options:

  1. A single global module for the company, where we would include the various elements. The view folder would contain subfolders dedicated to the different “sub-modules.”
  2. Create several modules based on our needs, in the same way Tryton currently does.

Right now, I’ve started development based on the first option. It’s working well since I’m still at the very beginning of the project. However, I’m concerned that this might gradually become disorganized as we make more progress in development.

.
├── CHANGELOG
├── COPYRIGHT
├── equipment.py
├── equipment.xml
├── icons
│   └── LICENSE
├── __init__.py
├── LICENSE
├── MANIFEST.in
├── message.xml
├── party.py
├── README.rst -> doc/index.rst
├── setup.py
├── tests
│   ├── __init__.py
│   └── test_module.py
├── tox.ini
├── tryton.cfg
├── trytond_my_module.egg-info
│   ├── dependency_links.txt
│   ├── entry_points.txt
│   ├── not-zip-safe
│   ├── PKG-INFO
│   ├── requires.txt
│   ├── SOURCES.txt
│   └── top_level.txt
└── view
    └── equipment
        ├── historic_form.xml
        ├── historic_list.xml
        ├── instrument_form.xml
        ├── instrument_list.xml
        ├── material_form.xml
        ├── material_list.xml
        ├── mbc_form.xml
        ├── mbc_list.xml
        ├── mfs_form.xml
        ├── mfs_list.xml
        ├── software_form.xml
        └── software_list.xml

(I removed all unecessary file and directory for this tree).

What do you think? Do you have any feedback based on your own experience?

Thanks in advance for your replies.

2

For a single instalation I will recomend having a single module with all of the customizations needed. Feel free to organize this module in the way it works better for you.

The reason for use a single module is that you will always have all the needed customitzations activated. Several modules are usefull when you want to activate or deactivate features depending on the database. But as far as you have a single company you will have a single database and you do not have the need to activate or deactivate features.

By using a single module with all the needed dependencies you can guarantee that by installing such module you will have exactly the same environment as you are running on production. This simplifies the deployment and maintenance of your customizations.

3

In the end, this is the same old question for any software project: Use one mono-repo or break it up into several sub-projects.

Personally, I have created several small modules for our company, because this works better with my line of thinking. Works what is best for you, and don’t forget, if you want to extract a single file or folder at a later time to an individual project, git can do this: Extract a subdirectory or single file from a Git repository

4

At B2CK we stopped splinting custom code in many modules long time ago (except when we backport a standard module to a series that does not have it). This is mainly because there is no main benefit when the code is only to be used for a deployment. But also quickly it became difficult to decide in which module a new customization must go.
We also organize the custom module by “main” tryton modules. For example every customization on party. goes into a party.py file, sale. into sale.py etc. This is mainly to find easily where is defined all the customization for a model. Also we have the naming convention for the view to use the model name with . replaced by _ for example party_party_list.xml or sale_line_form.xml etc.

We also tend to have folder structure with minimal level (I think we will soon use a dedicated folder for the ODT templates) but this is probably linked to the fact that we use console text editor so it is faster to open file in the same folder than having to type sub-folder name first.

About the repository structure we do not put the Tryton module as top-level because often we need to store in the repository files that are not related to the module like a Dockerfile, scripts, backported modules etc. A consequence of that is that we move the .flake8 and .isort.cfg, that the cookiecutter template create, on top of the repository.