Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Avatar

Re: 14.0 branches

by
Acsone SA/NV, Denis Roussel
- 09/10/2020 22:57:06
@Nhomar I don't get the cons you've got against pip for deployments. Maybe a misunderstanding or ...

On a wider point of view, if people relied on mechanisms like oca_dependencies.txt internally, maybe we can stay with both on this version as said before and open a discussion about that.

But as @Stephane said, this was already created on May. Maybe a lack of communication about it (resources to do things is always the bottleneck) before deployment.

Personally, I'd prefer pip as it allows better control. I share vision about letting things happen(feedbacks, bugs,...), debating and change. #trunkdevelopment


Cheers!


Le ven. 9 oct. 2020 à 21:42, Nhomar Hernández <nhomar@vauxoo.com> a écrit :
Pip has advantages and disadvantages [1] (and manages all for the sha's as well).

In general in deploy odoo with PIP is not even supported officially it is actually more a PoC in the OCA (which is nice but let's face it, it is not official).

I prefer keep the current one and enable both ways (we can be free to decide which one to use).

In general my opinion about pip is very bad (i personally don't think it is a nice way to be efficient deploying and maintaining).

Then, if we solved properly the problem already with the tools we have and we are going to a dependency hell (that even the python community has selve it yet in 30 years) why insist?

But again it is a democracy I think we need to mature more and more this topics and for me it is -1 change this without left proper support for both and test both ways.


El jue., 8 de oct. de 2020 a la(s) 14:22, Stéphane Bidoul (stephane.bidoul@acsone.eu) escribió:
Dear fellow contributors,

The 14.0 branches are being created as I post this message.

They are initialized from our new template repository that was created during the OCA Days sprint back in May [1]. This template is essentially a refreshed version of the linter configurations we have in 13.0. This new mechanism should make it easier to apply improvements across all repos in the future.

Special thanks to Jairo Llopis for his work on this topic.

I plan to provide a detailed walkthrough of all this during my OCA Days talk next week [6]. In the meantime, here are a few important things to note.

1. The project description in README.md must be updated manually by PSCs.

Since our project-level README were manually maintained and updated over a long period, it is difficult to reliably extract the variable content from them. So they are created afresh, and PSC are invited to update the repo description within the dedicated section of README.md. Please do not change the header and footer manually.

2. Travis installs dependencies with pip, including addons of other repos

This mechanism (activated by MQT_DEP=PIP in .travis.yml) does not use oca_dependencies.txt nor requirement.txt. It relies on __manifest__.py to discover dependencies from the 'depends' and 'external_dependencies' keys. Dependent addons are installed from the OCA wheelhouse [3], and python libraries are installed from PyPI.

The main expected benefits are:
- less redundancy (the manifests are enough to discover dependencies)
- reduce rippling effects to unrelated repos when an addon or python library does not install or misbehaves, since only the dependencies really needed by a repo are installed

If a PR depends on an unmerged addon or PR, create a file named test-requirements.txt at the repo root containing a line like this:


This mechanism has been tested on several repos in 13.0 and should be reliable. In case of problem, mention me in the PR and/or create an issue in OCA/maintainer-quality-tools repo. Alternatively, you can restore the old behaviour by removing the MQT_DEP=PIP line from .travis.yml. For the curious, the code of the new mechanism is in the OCA/m-q-t repo [4]

3. If you need local changes to the dotfiles let's discuss them

There are variables in the dot files, including .travis.yml [2]. To update them, the best way is to install copier [5], run "copier update" from the repo root, and answer the questions.

If you need other changes, you can apply them locally to resolve urgent situations, but that may make updates harder. So please open an issue in [1] to discuss if changes need to be made to the template.

As usual, don't hesitate to let me know of any issue.

That's all for now, folks. Happy migration!

-sbi


--
Stéphane Bidoul | @SBidoul
Acsone sa/nv | http://acsone.eu/ | +32 2 888 3120

_______________________________________________
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ú

phone nhomar@vauxoo.com phone vauxoo.com/contactus  

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

Reference