1. Mailing Lists
  2. Contributors
  3. Re: requirements.txt: Repository Level vs Module Level

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: requirements.txt: Repository Level vs Module Level

Re: requirements.txt: Repository Level vs Module Level

Avatar

Re: requirements.txt: Repository Level vs Module Level

by
ClosingAp Open Source Integrators Europe, LDA, Daniel Reis
- 11/02/2021 11:19:03
Hello Dmytro,

I feel that the best solution is to adopt pip-installed modules to your workflow.
That may need a learning curve, but it already solves all problems you describe.
I'm not the best person to get into the detail, but I'm sure there on people on this ML that can fill in.

If you prefer to go the Git way, my opinion is that you should to deploy OCA modules from their Git repos.
What I do is to have each OCA repo I need as a submodule, and then have a "link-addons" with symlinks for the modules used.
Only "link-addons" is added to the server addons path.
The requirements.txt is maintained manually - when a new "link-addons" symlink is added, is it has specific dependencies, the requirements.txt is also updated.

For requirements.txt inside modules, this is not an issue in recent Odoo versions, and external_Dependencies now supports the package name.
See https://github.com/odoo/odoo/issues/25541


I hope this is helpful
Daniel

On 11/02/2021 09:56, Dmytro Katyukha wrote:
Hi all,

As i see, usually in OCA repositories "requirements.txt" file with pip dependencies is located in the root of the repository and contains a list of all python dependencies for all addons in the repository. This way it works fine, when we clone full repository, and install all dependencies for all modules there, thus when user will try to install new module on DB, 99% that all python dependencies will be satisfied.

But, let's take for example repository partner-contact repository for Odoo 12.0 and let's try to add the module 'partner_email_check' to odoo server. For this task, i will use [odoo-helper-scripts](https://github.com/katyukha/odoo-helper-scripts) that can automatically resolve repository dependencies (including those specified by oca_dependencies.txt). So, at first i would try to fetch (clone) repository partner-contact, and in this case system will automatically fetch 42 OCA repositories following 'oca_requirements.txt', and also it will try to install python dependencies mentioned in requirements.txt. It is good for development. But installation this way on prod, may lead to a lot of unneeded modules, that polutes system with strange dependencies that are in some cases may be not installable (for example because of system dependencies).

To solve this reason, we started to use 'assembly' approach, that assumes that we have to create separate git repository with only addons needed on server. But in this case, if assembly repo created automatically, there is no way to get python requirements for module, if it is not specified in module directory. Looking for python dependencies in manifest is also not good, because there are python packages exists, that has different name for package and python module inside package.

So, may be it have sense to place requirements.txt inside module directory? Thus module's requirements will be always delivered with module, that will make easier installation of module. Also, i think this way, it will be much easier to generate setup.py files for modules, that will contain info about module's python dependencies.

Possible drawbacks may be in case, when different versions of python dep will be specified in different modules. But same is applicable for repositories.

What do you think about this?

With regards,
Dmytro Katyukha

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe


--
Daniel Reis
Managing Director
M: +351 919991307
E: DReis@OpenSourceIntegrators.com
Av Doutor Desidério Cambournac 12 • 2710-553 Sintra, Portugal


Reference