Le Sat, 24 Dec 2011 15:12:50 +0100, Cédric Krier <[email protected]> a écrit :
> On 24/12/11 07:45 +0530, Sharoon Thomas wrote: > > On Dec 24, 2011, at 3:09 AM, Cédric Krier wrote: > > > > > I think I have found a solution. > > > > > > First, we can have module extending Models define on other > > > modules but without depending on it. Like puting the code of > > > sale_shipment_cost_weight in carrier_weight but without making > > > carrier_weight depending on sale. > > > > Which means no separate glue module :) > > > > > Second, we just need to ensure the carrier_weight will be loaded > > > after sale_shipment_cost if it is installed. For this, let's > > > introduce an other keyword "extra_depends" that will behave like > > > "depends" but it will not be read when installing the module. > > > > This will not prevent tryton module loader from loading classes > > which were meant to be inherited (but will be loaded as new). For > > example if you inherit `sale.sale` and change the behaviour of a > > method, and if sale module is not in `depends` tryton will create > > `sale.sale` as a new model ? > > That's not a problem if you use Model and not ModelSQL. > Also that's why the other_depends is important to have the right order > if the module is there. I like the concept (and it looks something fun to implement!), but the name "other_depends" feels like a real dependency, I propose "follows". > > > > > > I think this design will allow to put glue code inside the module > > > without crappy hack and it will be explicit via the extra_depends. > > > > I dont know if this is really a dependency management problem ? (if > > I understood the problem right. Please correct me if I am wrong) > > > > I dont think these glue modules introduce new fields in DB and they > > only overwrite existing methods or introduce new methods to change > > the functionality. > > > > Why not provide an efficient helper function which checks if a > > module is installed ? > > > > ``` > > from trytond.tools import is_module_installed > > > > class Something(ModelSQL): > > def create(self, values): > > if is_module_installed(['sale', 'something_else']): > > # do something > > #anyway do this which is common > > > > I think duck-typing is better here and more pythonic. Could you provide an example of code? I'm not sure to see what is duck-typing here, do you talk about the kind of test we do for migration? -- Bertrand Chenal B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email: [email protected] Website: http://www.b2ck.com/ -- [email protected] mailing list
