1. Mailing Lists
  2. Contributors
  3. Re: 14.0 branches

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: 14.0 branches

Re: 14.0 branches

Avatar

Re: 14.0 branches

by
Acsone SA/NV, Denis Roussel
- 11/10/2020 17:40:22
Maybe we can do something in ocabot that generates an entry in oca dependencies if needed. @Stephane what do you think?

Le dim. 11 oct. 2020 à 17:32, Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com> a écrit :
I think the point is not to defend one method of another, although I'm also against pip, as it twists IMO Odoo requirements for adapting to pip. The point is that this unplanned change can impact in a lot of companies that have developed their deployment strategies based on what has been during a lot of years the OCA standard, without time to react and adapt.

Regards.

El dom., 11 oct. 2020 17:22, Simone Orsi <simahawk@gmail.com> escribió:
Hola Nhomar,

On Sat, Oct 10, 2020 at 12:21 AM Nhomar Hernández <nhomar@vauxoo.com> wrote:
Let's explain some rationale that the pip supporters are missing in the analysis (Daniel mentioned some of them).

It seems your rationale is not based on a full knowledge of the tool (and probably that's the case for me for oca-deps ;)).
Please, read below.
 
1.- With oca_dependencies.txt (better at module level, but not done yet).
Current possibilities:
    a. Refer to the official dependency (pip does that).
    b. SHA A on my repo which depende of SHA B of other repo which depends of SHA C of other repo, with the effort of having change 1 line on each repo. (I think pip does not do that).

With pip you pin the single module, not just the repo. It means that you can pin each version or hash atomically per each module. No matter if it comes from OCA or your organization, no matter if it comes from a PR. With oca_dependencies.txt is impossible to have the same preciseness of pinnings AFAIK.
 
    c. run git status on a deployed instance and know the dirty done manually (I used to support some customers with pip deployed instances and they have a mess).

What does this mean? If you mean "old style deployments where customers download the repo they want and they might edit files randomly" then I think you have another kind of issue ;P
In any case, you can install in edit mode the local repo, eg: `pip install -e path/to/repo/setup/$mod_name`
and you'll have the module installed from your local checkout where you can still run `git status`.
`pip freeze` will still tell you on which hash it has been installed.
The only downside of this is that you should install each module to make it installable in Odoo and fetch non local dependencies automatically.
 
    d. Some artifacts on t2d are done to even freeze odoo SHA.

I don't get what's the issue here. With pip you would do `pip install -e path/to/odoo` (or github url) and the current hash will be pinned.
 
    e. Deploy development/test/stable on your customer using the same source of information (that can not be done by PIP never), obviously if you decide to not touch the code (which is the ideal use case in the happy path you can, but it is not the use case on the speed of development vs deployment vs production X Q instances.

Can you elaborate on this? It's not clear what you mean.
 
    f. Refer to an specific branch on the oca_dependencies (for example to test a PR)

With this it is pretty easy to have linked your server - CI and developing environment with 1 command '$ t2d repo' or simply read the proper files to have the information.

As explained above, with pip you have much more granularity of pinning modules and versions from wherever you want.
 

2.- With PIP:

     a.- pip install module.
     b.- pray for nobody to change something because you will never know what happened.

Exactly the contrary: you install a specific version. If you want people to be able to edit things on live instances then you would install them locally w/ `-e` and then you'll still have your beloved `git status`.
 
     c.- pray the guy in charge updates the dependencies well.

If the module has the wrong dependency you are in trouble anyway. The good part is that you don't care about dependencies anymore unless you want to pin some fork or PR -> all the modules needed for that module will be pulled automatically, python dependencies included. If you installed a fork, pip freeze will produce a good requirements.txt with the right dependencies -> you can reproduce the same env.

     d.- If you change module B to fix module A to deploy module C you will do a nice Pray the developer is disciplined, if not kabum! only he can know what happened.

Again, can you elaborate on this?
 
I mean, PIP is nice for what it is designed for, but not for the messy odoo's world.!

I don't think it is a good idea to keep the world messy just because it started as a mess :)

But if you decide to be such a disciplined guy I am ok with you guys but let's test in the CI both, I am not against having them both, On one way or another one will fix the other, but we can't force everybody to follow an strategy that is clearly not designed for the speed 200 repositories change and the asynchronous work we do.

If you decide to go the path of killing the maintenance of oca_dependencies, as usual I support the Idea of the OCA but at least for us it will be worthless to maintain such flow if we are on our own to contribute and absorb the efficient layer that pip brings to the workflow.

What I do think is necessary is time from the ones that consume oca_dependencies on improve the documentations and make videos to explain the power because clearly it is misunderstood and oversimplified in your analysis.

I think the misunderstandings are everywhere in this thread :)

1. oca_dependencies.txt is not gone (to be honest, I asked if it was dead more for the rest of the world than for me, because I followed the process of the pip option introduction started in way back this year)

2. pip has way more capabilities than oca_dependencies.txt (as far I can tell), you just have to discover them

3. the 2 things can coexist and we can gradually transition to pip IF - and I think Stéphane was very clear on this - we don't have any major issue. To discover if we have issues, we should adopt it a bit more widely and provide docs and training about it -> at the OCA days we'll have some good talks on this.

4. As Stéphane mentioned, we could have a way to generate oca_dependencies.txt automatically to leave more freedom for personal/customer deployments.

That being said, there are maybe some other powerful features related to oca_deps that we don't see.
Probably it would be a good idea to have a comparison table.

I hope my point is better explained.

Same here :)

Abrazos,
S.

 

My 2 cents.

El vie., 9 de oct. de 2020 a la(s) 16:01, Roussel, Denis (denis.roussel@acsone.eu) escribió:
@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

_______________________________________________
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



--
Simone Orsi

Full stack Python web developer, Odoo specialist, Odoo Community Board Member, Freelance in love with open source.

_______________________________________________
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

Reference