On 24/12/11 15:57 +0100, Bertrand Chenal wrote: > 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 choose other_depends because it is the name in distutils.
> > > >
> > > > 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?
It depends of the cases but it could be like:
if hasattr(sale_obj, 'carrier'):
...
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: [email protected]
Website: http://www.b2ck.com/
pgpx8rJCDRC78.pgp
Description: PGP signature
