Community mailing list archives
Re: OCA and modules dependenciesby
Camptocamp SA, Joël Grand-Guillaume
I also want to say here that we're thinking within the board to create a kind of incubator for new commers / modules. This way, we will be able to identify the candidates to enter in the OCA.
So I can suggest that the project leader of every repo will be in charge of maintaining this inforamtion. The project leader is supposed to be aware of the devs going on in his area, so it make sense to me.
* Having in the README of the github repository (like : https://github.com/OCA/carrier-delivery) a way to find the work in progress of other non-OCA module sounds perfect to me
Hi,* Do not include any modules within OCA repository that depends on non-OCA modules => Too dangerous on mid-term
My personal vote goes for:
My personal vote goes for:
On Thu, Sep 11, 2014 at 12:31 PM, Sebastien Beau <email@example.com> wrote:
Hi all,I agree also that having dependency out of the OCA is a bad idea.Now we have to think how to handle this case (maybe some other people are in the same case).We have a usefull module working on V7 (direct printing of carrier label for french post), one of our dependency should be merge with the work of Camptocamp (file-exchange & connector-file), but for now we do not have the time/money to do this refactor (we plan to do it on V8 with a new customer).I am totaly ok to keep this module in an Akretion repository waiting to be merge in OCA module for V8 version (with the refactor of the dependency)Now the question is what should be the best practice to avoid a person of the community to do again a module for the french carrier because he didn't see any of this module in OCA branch?One of the solution can be for example to add in the README of delivery_carrier a link to our repo in order to inform the community that the french carrier module will be merge in V8?The aim is just to avoid a lost of visibility and waiste of time of redoing something existing.Maybe adding a new section in the Readme for all repository can be a good practice? We can even add even add this link when somebody start a new project, so we will avoid two team to start a similare project?It can be something like thatModule in joining OCA when ready=====================================Support of LA POSTE. Status (DONE 7 no PR, WIP 8 PR #XXXX). https://github.com/akretion/carrier-deliverySupport of USP. Status (WIP 8). https://github.com/.....Support of FEDEX. Status (SPECIFICATION 8). https://github.com/.....Support of german post . Status (PR #XXXX). https://github.com/.....What do you think?2014-09-11 12:01 GMT+02:00 David Beal <firstname.lastname@example.org>:ping seb2014-09-11 11:34 GMT+02:00 Leonardo Pistone <email@example.com>:I don't have a strong opinion on this. For sure, we shouldn't accept external depencies blindly. I'm just unsure whether we should put a hard rule or not. On the other hand, there could also be non-odoo python dependencies, and for those I would not try to restrict them. In my opinion odoo is already very isolated from the outside python world, so if someone finds a python package on pypi and wants to depend on it for an OCA module, it's OK by me.