RFC Roulier fondation for Odoo delivery carrier ! ? about delivery-carrier

[bealdav]

@angelmoya @rousseldenis

[rousseldenis]

That seems interesting indeed.

What do you think of this @OCA/logistics-maintainers ?

@OCA/core-maintainers

[rousseldenis]

Why not an organisation outside OCA but mainly maintained by @OCA/core-maintainers in the beginning of the story and joined by other dev over the time ?

It was just a ping 😄

[rousseldenis]

It could be a chance unifying (even if the final solution won't be perfect) and simplifying delivery carriers communication implementation with Odoo on the OCA side.

Moreover such modules are (maybe my impression) not easily reviewable for external people as they strongly depends on carrier communication implementation (and not really Odoo implementation).

So, adding carriers could become easy...

I'm not against creating a new organization but letting on OCA could be nice too and let it more visible.

[bealdav]

No problem on my side, I let others decide. Thanks a lot Denis

[pedrobaeza]

@bealdav the problems I see in the Python library approach are:

• We need to adapt standard OCA processes with Odoo modules for testing this library, deploying it, etc, which is a big maintenance burden.
• You can't anticipate changes in carrier, so you can find that you need to change the API of your library because of these changes and you'll end up with more changes: the one in the library and a change on each of the module versions calling the API in the new way.
• If module structure is the same across versions, it's easier to simply cherry-pick the commit with the changes.

so I think it's better to keep current approach.

[bealdav]

We need to adapt standard OCA processes with Odoo modules for testing this library, deploying it, etc, which is a big maintenance burden

It's not the case if we put the lib outside OCA: it makes a lib like any other one : you call it from odoo, lib answer : all the world can be in odoo don't you think ?

You can't anticipate changes in carrier ...

All changes are not breaking changes : Oca module only implements a sub part of carrier features : the financed ones, then no impact in most of cases.

Others can explain their point of view

[pedrobaeza]

It's not the case if we put the lib outside OCA: it makes a lib like any other one : you call it from odoo, lib answer : all the world can be in odoo don't you think ?

The question is not to put it outside or inside OCA. It's about QA processes: with Odoo modules, you have a lot of tools, and everything already set-up. With Python libraries, you don't.

[bealdav]

For sure, but it seems there are good practices to learn in the python world too (some good packages are inside).

As developer, I'm interested to be a python dev, not only a django dev or a oca dev.

Probably others dev too ! ?

Don't you ?

[pedrobaeza]

No, I want to be effective 😃

[bealdav]

Ok you won.

I can't win on the NIH syndrom ;-)

[pedrobaeza]

Hahaha. Mine is also another opinion like yours, so for now 1-1. Let's see others.

[bealdav]

Anyway the main purpose is to have more contributors on this technical topic and you don't taken account this part Pedro

[pedrobaeza]

Well, my reasons for not doing this are quite technical.

[bealdav]

Sorry but based on this example https://github.com/kennethreitz/requests (or a lot others), consider than OCA tools have better quality than python package seems presumptuous and make irrelevant reasons

[rousseldenis]

Well, my reasons for not doing this are quite technical.

So, we are all technical people and I think this should not be a limitation. We have many examples under the OCA depending on external libraries maintained by OCA itself.

My advice is to make that repository, let people who want to use it, implement it in their particular delivery modules (maybe with a base_roulier under delivery-carrier) and let see.

It allows to let the implementation becomes more mature with time and not introducing a big-bang.

What do you think @pedrobaeza @bealdav ?

[pedrobaeza]

@bealdav I'm not saying OCA tools have better quality. It's simply that we, OCA prepared, are not so prepared for handling Python libraries than Odoo modules, and I prefer to not needing to learn that being a residual part of my work.

Said that, if you want to go that way, you can do it, even under OCA umbrella, but I won't be able to provide you with the foundation from OCA for the CI tools and so on, as I do for the rest of the repositories.

[bealdav]

I understand perfectly @pedrobaeza . You make so much for OCA, I don't want ask you more efforts on other topics. Thanks a lot

[guewen]

+1 for a Python lib, it totally makes sense to me. Regarding QA that needed a lot for development for Odoo: it is also due to Odoo's nature and the fact it uses its own test toolchain. Everything already exists for testing Python libs.

[bealdav]

Thanks for your answer @guewen , please could you give a word here

https://odoo-community.org/groups/contributors-15/contributors-136645?mode=thread&date_begin=&date_end=

Thanks

[rousseldenis]

@OCA/core-maintainers could we move forward here?

[bealdav]

ping @hparfr

[hparfr]

Said that, if you want to go that way, you can do it, even under OCA umbrella, but I won't be able to provide you with the foundation from OCA for the CI tools and so on, as I do for the rest of the repositories.

Fair enough

[rousseldenis]

@bealdav @florian-dacosta @OCA/core-maintainers @hparfr What is the status of this ?

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.