OCA Packages and it's dependencies

[marioolofo]

Hello everyone,

I'm creating a machine with Odoo 16.0 and adding the OCA l10n_br packages according to the needs I identified with my client, but I'm not sure if I'm doing it correctly or if the process ends up being slow: for each repository I add to my addons folder, I have to add it to my odoo.conf, restart the service, log into Odoo and the applications, update the packages, and try to activate them.

Usually, this process reports that there are dependencies that are not installed, so I go there, find the repository for that dependency, clone it, update odoo.conf (in cases where a repository has multiple packages), restart the service, activate the dependency... and sometimes this dependency depends on other packages, and the cycle never ends.

Not to mention that sometimes it's not easy to find a package's repository, as the oca-community shop often doesn't show where the package comes from.

I don't know if there's an easier way to download every package and its dependencies, so what I'm doing right now is:

1. I have a virtual environment where I add all the Python packages from all the requirements.txt files.
2. I have Odoo and the addons installed in the /opt/odoo16-ce and /opt/odoo16_addons directories.

So, I created a script that scans all the Odoo and addons directories for manifest.py, creates a list of packages and their dependencies, and tells me which dependencies were missing for each package.
With this list, I still have to go through the initial process of hunting down the dependency repositories, but I can be sure that eventually I'll have them all added to the project... but I don't! There are cases like edi_endpoint_oca, which has an endpoint dependency, but this package doesn't exist for version 16.0.
Or product_attachment_zipped_download, which depends on attachment_zipped_download, but I can't find it anywhere.
Or the case of membership_extension, which exists in the membership package, but the website has no information about it.

Conclusion: is this really the case, or am I being really stupid, and is there a practical tool that can solve this for me?
If you're curious, I can post the Python script I created here.

Thank you.

[rvalyi]

Ola @marioolofo

basicamente a Odoo não facilita muito para vc instalar seu próprio Odoo local. Ela nao respeita bem os padrões setuptools, tem um monorepo gigantesco etc. A gente pode suspeitar alguns motivos:

• se é dificil instalar vc vai ter uma certa pressão para ir no SaaS/Odoo sh dela
• os desenvolvedores da Odoo tendem a viver numa bolha onde eles não tocam projeto (a Odoo vende, os "parceiros" se viram para implementar mas os desenvolvedores da Odoo nem costumam tocar projetos Odoo reais, geralmente tem a diretiva de ignorar a OCA...)
• nem sempre os caras da Odoo são muito bons... No inicio os caras vieram do software livre, começaram sem dinheiro. Hoje os caras que deu para contratar qdo não tinha dinheiro são os os senior na Odoo. De fato os cabeça da OCA tem um nivel completamente diferente do nivel medio dos desenvolvedores da Odoo...

Nisso quem pretende tocar projetos Odoo reais tem que ser mais inteligente e varios integradores acabaram desenvolvendo ferramentas para ajudar isso. Mas hoje nem existe um "padrão unico" da OCA de fazer. Talvez o jeito mais próximo desse padrão seria esse:
https://youtu.be/oQbrZoVttt8?si=QlECLnIJTVaWr-xO

algumas outras ferramentas que alguns integradores fizeram:

• https://github.com/Tecnativa/doodba
• https://github.com/akretion/docky
• https://github.com/acsone/git-aggregator

Tem várias questões: tem aquela ferramenta que é mais facil para aprender mas tem a outra que é mais produtiva quando vc trabalha com muitos projetos etc... o git-aggregator é fondamental para trabalhar com a localização.

Uma outra dica: os autores de alguns pacotes que a gente usa não mantem eles direito... Nisso apesar de codio atualizado na master, falta fazer o release dos pacotes python erpbrasil.base, erpbrasil.assinatura e o pacote erpbrasil.edoc tem realmente um problema mais fondamental e provavelmente vai acabar sendo substituído apesar de funcionar do jeito que ta ou com esforços mínimos.

Enfim nisso, isso faz que esses últimos pacotes tendem a ter problemas de compatibilidade de versão suteis.

Na duvida, eu te aconselho de olhar as versões nos requirements.txt e test-requirements.txt do repo e eventualmente conferir com as versões que vc encontra no inicio dos logs dos testes da CI do projeto.

Por fim sei que isso realmente não deixa o projeto accessível. Mas veja que quem hoje não mantem os pacotes estavam se apresentando como aqueles salvadores da patria uns 2 anos atras ainda, complicado...

A tendência é isso tudo melhorar. Ultimamente tem pessoas serias como da Escodoo e da Engenere que começaram a contribuir e a tendência é não voltar para tras.

Uns dias atras vc perguntava sobre versão 18. Pois veja bem, a gente so vai conseguir manter as coisas atualizada se a gente adotar uma qualidade de psicopata no codigo assim como tende a ser nos outros repo da OCA. So assim fica viável migrar os módulos no automático e propagar os fixes entre as branches. Fizemos esse trabalho de limpeza por isso o "atraso" nas versões.

Por fim vc vai pensar que tudo isso é bem complicado. Verdade, se vc não tiver uns 2 anos de Python profesional (tipo Django ou coisa do tipo), vc dança. Mas veja que mesmo se a gente gastar tempo de fazer uma receita do bolo pronto em vez de cuidar dos aspectos mais fondamental do projeto (limpar, migrar etc..) o que aconteceria, seria que vc instalaria em 2 dias sim, mas depois quebraria a cara no primeiro bug que encontraria do mesmo jeito. Ou seja só ia ganhar 1% na curva de aprendizado e ia queimar o projeto gostoso porque um monte de gente que hoje vai quebrar a cara com Odoo Enterprise iria quebrar a cara com a OCA e reclamar do projeto depois. E a gente aqui não tem a grana para fazer o damage control disso. Então é bom a gente adequar a promessa do projeto com a realidade... Mas novamente a tendência é tudo isso evoluir rapidamente. Se vc comparar as branches 12, 14 e 16 vai ver uma evolução muito grande ja.

[rvalyi]

Sorry for the Portuguese everybody. @marioolofo as you asked on the OCA/l10n-brazil in Portuguese 2 days ago, from my cell phone I didn't see you were now asking in the generic OCA discussion forum and answered you in Portuguese. But nonetheless I think it still point you to the best content about what you asked for. Notice we created a docky template for projects with the Brazilian localization akretion/docky-odoo-brasil#19

[marioolofo]

Hi @rvalyi, thanks for the reply.

I wasn't sure if I could create the discussion in Portuguese, so I ended up changing the question to English.
I asked here because I thought it had more to do with the issue of l10n_br package dependencies being on general packages.

Uns dias atras vc perguntava sobre versão 18. Pois veja bem, a gente so vai conseguir manter as coisas atualizada se a gente adotar uma qualidade de psicopata no codigo assim como tende a ser nos outros repo da OCA. So assim fica viável migrar os módulos no automático e propagar os fixes entre as branches. Fizemos esse trabalho de limpeza por isso o "atraso" nas versões.

Exactly what you said, we went after version 18.0 because it was the "pushed" version with the enterprise, but I managed to set up an environment with version 16.0 and some OCA l10n_br modules and I was able to show that you, in addition to being a localization reference and having everything we need to get started, keeping the system open source would be much more advantageous in the long term, both in terms of platform stability and workforce, and financially.

Nisso quem pretende tocar projetos Odoo reais tem que ser mais inteligente e varios integradores acabaram desenvolvendo ferramentas para ajudar isso. Mas hoje nem existe um "padrão unico" da OCA de fazer. Talvez o jeito mais próximo desse padrão seria esse:

I watched it, but initially I take care of the maintenance and configuration of Amakha's servers, and until today I haven't had time to stop and create a Kubernetes environment, so I use DO droplets and run the projects on real hardware, it ends up being cheaper because a cheap server can run what Docker can't.

Por fim vc vai pensar que tudo isso é bem complicado. Verdade, se vc não tiver uns 2 anos de Python profesional (tipo Django ou coisa do tipo), vc dança.

I don't see a problem with that. I like poring over code and understanding the nuances until it works perfectly. I've been doing this for 20 years, lol.
I know the basics of Python, but my background is in embedded systems, assembly, C/C++, and more recently Go. About eight years ago, I started working with JS and TS, along with Angular and React. I'm more skilled in front-end development than back-end development these days, but nothing stops me from building some APIs and medium-complexity systems.

Taking the opportunity, is there any OCA package similar to the messaging one, but with rich text and as an information feed to be used as an employee home screen in the admin?

Thank you very much, I will try to continue even though this dependency tree is incomplete and if any package is really missing, I will ask again.

[rvalyi]

Taking the opportunity, is there any OCA package similar to the messaging one, but with rich text and as an information feed to be used as an employee home screen in the admin?

Not sure what you were asking for exactly (may be you can explain better). Would this module suit your needs
https://github.com/OCA/server-ux/tree/16.0/announcement ?

Thank you very much, I will try to continue even though this dependency tree is incomplete and if any package is really missing, I will ask again.

So the point of the video is you can install packages both with pip or uv and they will resolve the dependencies for you as with any Python module. But the point is in real life you'll easily need modules that are not so mature, that are evolving fast or that are so complex that you'll need to patch them in some ways to fit your needs. And sadly OCA/l10-brazil certainly falls into this category of "so complex+fast evolving" that you'll need to patch/adapt it. That's why I pointed you to the git-aggregator tool from Acsone that we all use in Brazil. Eventually you can install modules using pip or uv and complete the addons-path with git and git-aggregator.

When you are unsure about which repo an OCA module is to be found, you can simply search it in the "shop" here https://odoo-community.org/shop (BTW the OCA will migrate its Odoo instance to 18.0 so this UI will improve) and in the top of the page you'll find the link to the repo. You could also search it on pypi.org, eventually adding the "odoo-addon-" prefix to it. For instance https://pypi.org/search/?q=odoo-addons-mis-builder&o=

Finally it's great, it seems you have enough tech background. What you'll also need to succeed is ERP knowledge and likely a very good deal of fiscal knowledge here in Brazil if you pretend to implement it in a company from the normal fiscal regime. Cause you'll quite easily be able to do the right things with Odoo, but sadly you'll also easily configure it all wrong if you don't master this complex part here.

Finally, if you pretend to go live in 6 months or later, you can learn/train on v16 and you'll likely be able to go live on v18 with the l10n-brazil modules migrated. The v16->v18 migration is pretty trivial. As I explained it's just that we wanted to do some more extra cleanup before migrating so we can easily support our customers both on v16 and v18. Think we will need to propagate the changes for the fiscal reform to the fiscal and fiscal documents modules... That need to be fluid enough. And in these last PR's we aim at having some minimal compatibility with the l10n_br module that is with the Odoo Enterprise module tree, at least for the master data. Even without doing any marketing, some 3 companies screwed on Odoo EE v18 are calling us every week. If we have this minimal compatibility there are at least some of them we will be able to rescue in the future...

[marioolofo]

Hello @rvalyi

Not sure what you were asking for exactly (may be you can explain better). Would this module suit your needs
https://github.com/OCA/server-ux/tree/16.0/announcement ?

Not exactly that, I was looking for something like the messages channel but with the option to send rich text, add images and show in full width, more like a feed from social apps for important messages to all.

So the point of the video is you can install packages both with pip or uv and they will resolve the dependencies for you as with any Python module. But the point is in real life you'll easily need modules that are not so mature, that are evolving fast or that are so complex that you'll need to patch them in some ways to fit your needs. And sadly OCA/l10-brazil certainly falls into this category of "so complex+fast evolving" that you'll need to patch/adapt it. That's why I pointed you to the git-aggregator tool from Acsone that we all use in Brazil. Eventually you can install modules using pip or uv and complete the addons-path with git and git-aggregator.

Ah I see, yes indeed the git-aggregator seems to be a tool to do what I'm doing manually right now, I'll try to use it and see what happens, thanks.

When you are unsure about which repo an OCA module is to be found, you can simply search it in the "shop" here https://odoo-community.org/shop (BTW the OCA will migrate its Odoo instance to 18.0 so this UI will improve) and in the top of the page you'll find the link to the repo. You could also search it on pypi.org, eventually adding the "odoo-addon-" prefix to it. For instance https://pypi.org/search/?q=odoo-addons-mis-builder&o=

Thanks, in pypi the package named endpoint shows that it's inside the web-api repository, and the attachment_zipped_download is found and now I know it's in the knowledge repository! This information is lacking in the shop, but now I have two places to search =D.

Finally it's great, it seems you have enough tech background. What you'll also need to succeed is ERP knowledge and likely a very good deal of fiscal knowledge here in Brazil if you pretend to implement it in a company from the normal fiscal regime.

Yes, I have a business partner that have the required knowledge as he worked with SAP and others for 10 years now.

Finally, if you pretend to go live in 6 months or later, you can learn/train on v16 and you'll likely be able to go live on v18 with the l10n-brazil modules migrated. The v16->v18 migration is pretty trivial.

Good to know, but I'm afraid that I'll have to use the 16.0 to go to production ASAP and migrate to 18.0 in a later time without hush. This version has almost everything they need, and I agree with you in that we need to let the updates to other versions happen over time in an organized and mature way.

The only package that they need and OCA don't have is the PagBank gateway integration.
I already have the integration in my ecommerce and I'll try to port it to Odoo in the next week.

Even without doing any marketing, some 3 companies screwed on Odoo EE v18 are calling us every week. If we have this minimal compatibility there are at least some of them we will be able to rescue in the future...

Probably 4 if we hadn't found odoo-community and had an enlightening conversation a few days ago =D

Mario

[rvalyi]

I see indeed attachment_zipped_download repo information is indeed missing in the OCA 'shop' app. It happens for a few modules and I'm not exactly sure why. Generally picking a different "serie" will show the repo info but not here strangely, In any case the OCA shop is a legacy app that is expected to but completely revamped by the end of the year.

Finally, v16 for Brazil is a very solid choice and yes you could perfectly migrate later no rush. As we are still making big changes to get the basic EE edition compatibility ahead, make sure you restart you Odoo with --update=all or the required modules when you update you l10n-brazil clone to update yoru database accordingly (the big changes are expected to be over in less than 10 days), an option you could use for this is click-odoo. Migrating from v16 to v18 isn't going to be that hard.

[marioolofo]

I see indeed attachment_zipped_download repo information is indeed missing in the OCA 'shop' app. It happens for a few modules and I'm not exactly sure why. Generally picking a different "serie" will show the repo info but not here strangely, In any case the OCA shop is a legacy app that is expected to but completely revamped by the end of the year.

Finally, v16 for Brazil is a very solid choice and yes you could perfectly migrate later no rush. As we are still making big changes to get the basic EE edition compatibility ahead, make sure you restart you Odoo with --update=all or the required modules when you update you l10n-brazil clone to update yoru database accordingly (the big changes are expected to be over in less than 10 days), an option you could use for this is click-odoo. Migrating from v16 to v18 isn't going to be that hard.

Thanks, click-odoo seems to be very useful for me.
The --update=all is something that I'll keep in mind, another thing that I'll do is run my script to check if any dependencies are missing again, as I see that there's some packages that exists on 16 but not in 18 and vice versa.

I have an idea of mapping all repositories of OCA with it's respective addons for version 16.0 (for now), this way my script can automatically clone all the dependencies of a given addon when I choose to add it to the client's Odoo instance (and maybe create a yaml file that can be used with git-aggregator to apply patches and replicate to the production server more easily).

Thanks

Mario