Contributors mailing list archives

Browse archives


Re: 14.0 branches

Vauxoo, Nhomar Hernández
- 14/10/2020 04:05:05

El mar., 13 de oct. de 2020 a la(s) 01:57, David Beal ( escribió:
+1 for generated requirements.txt and oca_dependencies.txt too if possible

IMHO I think that can not be optional but mandatory for the sake of stability and take 2 versions to stabilize.

I wonder how will be the management of a wired repository.

I mean:


folder git/repo branch

And force the dependency be taken/updated from it.



I love the effort that has been made to autodiscover the dependencies from __manifest__
Please don't discourage it with arguments about your own deployments.
You may use pip in OCA workflow as proposed, and use git for your development/production as I do everyday

You have to decouple things for your own interest

my 2 cts

Bonne journée

David BEAL -
Odoo Intégration / Développement

Le mar. 13 oct. 2020 à 08:47, Stefan Rijnhart <> a écrit :
+1 for generated requirements.txt and oca_dependencies.txt


On 12-10-2020 14:52, Alexandre Fayolle wrote:
I'm happy with generated requirements.txt and oca_dependencies files. This will remove some errors caused by manual management of these files anyway.

Regarding oca_dependencies: I use them to easily find when an addon is defined, where to direct a contribution, etc. I also happened to "discover" some OCA repositories that way.

Regarding requirements.txt: the latest version of Odoo's runbot uses these to install the requirements. It will help using OCA repositories on, and I think it is a valuable service we provide to our users.

Regarding pip installation of addons, I'm not sure this is available on, and I think this is a use case we should not underestimate.

Le lun. 12 oct. 2020 à 09:07, Mignon, Laurent <> a écrit :
HI Folks,

I think it's very important to keep the debate open and to present your arguments in a constructive way.I must admit that I am a little saddened to read accusations of half-truths when the process is meant to be open and constructive. It seems to me that the goal here is not to impose a new methodology but to confront our practices with those of the python community. The fact that the aim of this approach is to simplify the maintenance of our OCA repositories as well as to reduce the learning curve for new developers, I find this more than remarkable and valuable.

Since many integrators' tools/processes are now based on the oca_dependencies.txt and requirement.txt files, in view of the discussion it seems necessary that somehow these should be available again. It seems to me that automating the generation of these files would be more than beneficial because it would avoid inconsistencies in the future for all the processes based on them.

Over the years I have used different tools and methodologies to try to improve the management of our dev -> prod processes of our python projects. I personally contributed to buildout, imagined and wrote git-agggregator, .... The goal has always been to improve the traceability and reproducibility of our developments and deployments. Today, and thanks to the evolutions around pip, I'm happy to see that python tools allow me to improve and simplify these processes without having to use specific tools. (While bringing more freedom and features).

Is it possible to envisage an evolution of our integration mechanisms towards pip support while retaining the necessary elements for the other approaches developed by the various parties?

I find it motivating to confront this approach with all the use cases of each other in order to determine the limits of this approach. This will at least allow us to improve our knowledge and perhaps correct certain ideas.


Post to:

Post to:


Nhomar G Hernández

Vauxoo | CEO

¡Construyamos algo genial!
Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar

México · Venezuela · Costa Rica · Perú

phone phone