openerp-community team mailing list archive

[Alexandre Fayolle <alexandre.fayolle@xxxxxxxxxxxxxx>]

+1, I still feel this is needed.

Fabien : I've seen at least one re-implementation of MRP in the wild,
which are obviously not compatible with the official mrp addon. Just
having a comment in the description of the module is not enough : we
need something stronger which prevents accidental installation of a
known incompatible module.

Same thing for customer specific modules : if I'm forced to completely
rewrite a API function (e.g. it lacks an extension point) without
calling the super() implementation of that method, I generally won't fix
this in all the standard addons which reimplement that method (and call
the super() implemenation), if they are not installed on the customer's
instance. However, having a quick way to tell that such modules are
incompatible with the specific one I'm installing will ease the work of
maintainance as they will know something has to be done before one such
new module is installed during the application lifecycle.

-- 
Alexandre


On 17/08/2013 16:03, Fabien Pinckaers wrote:
> Hi,
>
>> Some community modules are incompatible with each other, or with core
>> modules. It may not be desirable but it is sometimes unavoidable and
>> is a fact today.
>
> Do you have some examples of incompatible modules where it's unavoidable?
>
> My first though would be to understand why a module may create
> incompatibilities and fix what could be fixed. (e.g. on_change stuff
> may create incompatibilities, but it's fixed with the new API)
>
> Developing a module that create incompatibilities is usually the sign
> of a bug (e.g. a module that add a required field without a default
> value -> this creates incompatibilities but it's a bug as they are
> plenty of others way to trigger the bug) 
>
> I have only one reason in mind where incompatibilities are created and
> it's not a bug; modules embedding JS libs that are incompatible. It's
> not a bug but it's avoidable.
>
>> Discovering such incompatibilities is a painful process, and there is
>> no structured mechanism to communicate about them once they have been
>> (re)discovered.
>>
>> This has been discussed in the past [1], but was not followed by
>> concrete steps, AFAIK.
>>
>> As a first step, would the community agree with the addition of a
>> field named "incompatible" in __openerp__.py, providing a simple list
>> of module names that are known to be incompatible?
>>
>> This would be beneficial to the community, even without support in
>> the core or apps.openerp.com <http://apps.openerp.com>, by letting
>> module maintainers declare known incompatibilities.
>>
>> Populating this field can follow the normal merge proposal and review
>> process.
>>
>> If it gains traction, tooling may support it in a second step.
>
> Looks like a good approach as the biggest risk is that those extra
> fields are not maintained.
>
> Another way is to consider incompatibilities as bugs. (as per my
> comment above) So, anyone can easily fill a bug on a branch he doesn't
> own, it's way easier than going through the merge proposal process.
> (and all the issues related to a module are visible in the same list
> of bugs)
>
>> Note that I consciously avoid the topic of version dependencies as
>> this would open a bigger can of worms.
>
>
>
>
>> The only purpose of the present proposal is to provide a human and
>> machine readable way to document partitions in the addons landscape.
>>
>> Cheers,
>>
>> -sbi
>>
>> [1] https://lists.launchpad.net/openerp-expert-framework/msg00840.html
>>
>> Stéphane Bidoul | @SBidoul <https://twitter.com/SBidoul>
>> Acsone sa/nv | http://acsone.eu/ <http://acsone.eu/> |+32 2 888 3120
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-community
>> <https://launchpad.net/%7Eopenerp-community>
>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>> <mailto:openerp-community@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~openerp-community
>> <https://launchpad.net/%7Eopenerp-community>
>> More help   : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp


-- 
Alexandre Fayolle
Chef de Projet
Tel : + 33 (0)4 79 26 57 94

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac Cedex
http://www.camptocamp.com