Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: 14.0 branches
by+1 for generated requirements.txt and oca_dependencies.txt too if possible
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 everydayYou have to decouple things for your own interestmy 2 ctsLe mar. 13 oct. 2020 à 08:47, Stefan Rijnhart <stefan@opener.am> a écrit :+1 for generated requirements.txt and oca_dependencies.txt
Stefan
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 Odoo.sh, 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 odoo.sh, and I think this is a use case we should not underestimate.
Le lun. 12 oct. 2020 à 09:07, Mignon, Laurent <laurent.mignon@acsone.eu> 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.
Regards
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Nhomar G Hernández
Vauxoo | CEO
¡Construyamos algo genial!
Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar
México · Venezuela · Costa Rica · Perú
Reference
-
14.0 branches
byAcsone SA/NV, Stéphane Bidoul-
Re: 14.0 branches
byClosingAp Open Source Integrators Europe, LDA, Daniel Reis