Community mailing list archives

Re: OCA project: __unported__ folder considered painful

Akretion, Raphael Valyi
- 03/11/2015 11:49:16
2015-03-11 8:27 GMT-06:00 Pedro Manuel Baeza Romero <>:
Nhomar, one module (or also auto_install modules) per repo can be achieved, but joining via "git subtree" in the current repos. You will get the same number of repos to deploy. Also contributions to existing modules will be similar, but working on the subrepo. The only problem I see with this is with new modules, that need to create a new subrepo, and link it to the general repo.

I tested this option.

AFAICK it do not "autocommit" when one tree change on its repository, let's say:

I have a repository with:

--> subtree repository module_a.
--> subtree repository module_b.
--> subtree repository module_c.

Then, somebody make a commit on repository_a.
Its .travis trigger its tests may be red/yello and so on and repostory is not know of such change.

I think it is feasible, but in our complex multimodule enviroment with vertical dependencies (the ones in / and horizontal dependencies (the ones that are not mandatory but can cause conflicts for example the ones in res.config modules_* fields) it is really not feasible in practical PoV.

Again I tested internally and after 2 weeks I return my changes again. (and we have 5 persons in charge of such job) I don't want to know haow manage this complex dependency matrix with 500 modules and N combinations.


Saludos Cordiales
Nhomar Hernandez

Hello Nhomar, 1 repo = 1 branch works and it works really well when we have the right decent tooling, more specifically the right package manager to deal with that dependency matrix of 500 modules and their versions for us in a systematic way, including for the automatic testing. Like in Ruby there is Bundler, and it has been ported to Python as pundler (not sure how maintained though)

Ask anybody about something like Gitlab which is a Github clone in Rails, it's full featured and very stable.
Now look the equivalent of their dependencies with specified version: (forget the development section)

Now look how this is deepened and how each dependency revision can be recursively frozen and tested against that frozen version so that deployed version is fully tested:
That is more than 800 dependencies which are all pinned!

It absolutely works and in 10 years of software engineering I never mate a better dependency management system. I could mention you dozens of such other stable and extremely modular projects. Instead I'm very frustrated about the module management in Odoo and everytime I should deal with it I get the impression to go back to the middle age of dependency management.

Now it's true with Odoo we don't have real python package and we don't have a Bundler yet. So IMHO it's okay to have a workaround for now, a suboptimal transitional solution, but let's don't throw out the baby with the bath water. moreover it's not because OCA have 50 sale realted modules that you want to install many of them on the same instance. I would even say the contrary: you just need 2 for sale, 2 or 3 for purchase etc...

I'm not happy with the __unported__  folder either. Now I'm not sure yet what I prefer as a work around. I should think more about it. But I would say: don't included unported modules in the branch and list them instead in a README or TODO file so they are not forgotten while unported. Hopefully I confirm my position later. Thank you all for bringing this topic on the table again.

Raphaël Valyi
Founder and consultant
+55 21 3942-2434