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, Stéphane Bidoul
- 11/10/2020 19:14:58
As said, my only goal is to improve the OCA contribution workflow.
Of course, I don't want to force any specific installation method onto integrators workflows.

So let's try to keep the discussion focused.

To be a little bit more specific, here are some aspects that the new method improves:

Less Redundancy

What is in requirements.txt must be added manually and is redundant to addons manifests. oca_dependencies.txt is also redundant and the information can be found elsewhere.

Better testing of dependency declarations

We don't test external python dependencies declarations in manifests because we rely on a redundant, manually maintained requirements.txt
pylint-odoo helps but there are limits to what it can detect.

Also, we publish wheels for OCA addons because it is by far the easiest for newcomers (and veterans alike I should say) to discover dependencies (addons and external python dependencies). Bad dependencies makes for a suboptimal user experience for newcomers installing the wheels.

Reduced blast radius when addons are introduced with specific test requirements, or "exotic" test requirements break

When an addon has specific test requirements it has side effects in all repos that transitively depend on its repo, whether or not the modules are actually needed. When installing dependencies at the addon level instead of the repo level, we drastically reduce the blast radius of such things. Examples: server_environment that required a mandatory option in odoo.cfg. Or an obscure dependency of some rarely used addon in server-tools that suddenly breaks on PyPI and impacts all repos that transitively depend on server-tools because they all end up installing all requirements.txt of server-tools. When that happens, the impact is usually so wide that everyone has to rush to find solutions to unlock the situation. If the impact is contained to the addon and those that depend on it, that buys us more time to find good solutions.

Finer grained approach to declaring unmerged dependencies

With the optional test-requirements.txt, you can declare override dependencies to target unmerged individual addons like this:
This means you can reference several PRs of the same repos, or several addons of different PRs in another repo (I don't think one can do that with oca_dependencies.txt, where you reference whole repos).

[BTW, @Moises, to answer your question above you could use such references to your own repos. And it reduces the need to use git-aggregator too. - but I digress]

To close the list, I'd say dependency management is hard and relying on the broader python ecosystem to solve the problem can only help us in the long run (pip in particular is going to release a new sophisticated dependency resolver later this year). And Odoo is not particularly messy nor does it have anything very special in that matter.

So how can we progress?

For the reasons above, I'd like to move out of the status quo.
In the past the only arguments I had received were of the general class "I don't like it", but nothing really concrete.
So yeah, I guess I'm pushing a little bit in the hope of getting solid feedback.

No harm is done (there are no cross-repo dependencies in v14 branches yet :) and as said, we can easily push an update to .travis.yml.

And the good thing is that the feedback is coming:
- At this point I see Moises who says it relies on oca_dependencies.txt in its workflow.
- Daniel mentioned a documentation value of oca_dependencies.txt.

A few questions:
- @Moises, do you rely on requirement.txt too in your own workflow ?
- Do others rely on it ? (for instance, does Dooba need oca_dependencies.txt, requirements.txt in OCA repos ?)

If we conclude that oca_dependencies.txt and/or requirements.txt must be preserved in all repos in v14 (and I'm totally fine with that), we can then discuss how best to do it. Either manual with e.g. PIP mode on Odoo and OCA mode on OCB as Moises suggested - but that would be a burden for contributors to understand and maintain both approaches. Or try to generate oca_dependencies.txt and requirements.txt, which should be feasible at first sight, but that's more work. Or keep the status quo :/

Cheers,

-sbi


On Sun, Oct 11, 2020 at 7:06 PM Stéphane Bidoul <stephane.bidoul@acsone.eu> wrote:
On Sun, Oct 11, 2020 at 5:41 PM Ivan Todorovich <ivan.todorovich@druidoo.io> wrote:
Would testing with PIP also catch compatibility errors between modules that don’t depend on each other? Or errors with modules that are in the upstream chain of dependencies?

@Ivan the new method does not change what is installed on the test database. What changes is only the list of addons present in the addons path. So the scenarios you mention should work just like before.

-sbi

Reference