A Divendres, 23 de desembre de 2011 17:19:51, Cédric Krier va escriure: > On 23/12/11 16:39 +0100, Albert Cervera i Areny wrote: > > I think we need that compatibility/dependency to be in the module > > definition. So if the user installs the modules "purchase_shipment_cost" > > and "stock_account_ango_saxon", then > > "purchase_shipment_cost_anglo_saxon" should be automatically marked for > > installation as if it was a dependency. > > So both module "purchase_shipment_cost" and "stock_account_ango_saxon" > need to know each other. There is no such option in distutils and from > my Gentoo packager experience, I never saw such dependencies.
Well, don't know about those, really. But Debian has an "incompatible" and "suggested" options. Maybe something like "suggested" could be enough. But if you allow the user to install those modules that are known to be incompatible... I don't know I think we should try to do better and suggest the module that makes the system work. > > That > > information should probably come from the > > purchase_shipment_cost_anglo_saxon module, or it may come from any of > > the other two. > > It can not because you can have the two modules without this one. It depends on how you express that. It could be an in "purchase_shipment_cost_anglo_saxon" that says: "required" if X and Y are installed. > > In case of the approach of modifying the existing module, maybe the > > __tryton__ file should also inform that the module takes into account a > > given set of otherwise incompatible modules. > > I think it will be just an extra_dependency in setup.py (and in > INSTALL). > > > I think we need a way to know which modules > > require some others > > This is already there. I meant something like the conditional I expressed above. > > or check for their existance. > > I think extra_deps is enough. Yes, that could be enough. > > As you said, if a module requires another one to be modified it may not > > be possible to develop it for a previous version which I think it is > > very bad so it sounds as the wrong solution from this point of view. > > Not too bad as we have release every 6 months. And moreover, it is > already the case for many new modules like the groupby design change for > the sale_supply_drop_shipment. I agree that the 6 month cycle helps a lot here but I think the framework should be ready for both approaches: glue modules and code module checks. The latter is ok for core modules but the former will be required for modules outside core. So improving the way to express the kind of dependencies (with things like suggest or conditionals) between modules can become an interesting feature. -- Albert Cervera i Areny http://www.NaN-tic.com Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog -- [email protected] mailing list
