Hello,
As it costs nearly nothing to implement, I would advocate supporting basic incompatibilities too as suggested. The way OpenERP is currently coded with badly modular on_changes and many fat methods make full compatibility an utopia within say the 2 next years scope. IMHO it's more pragmatic to assume this and start informing the masses about basic imcompatibilities during the transition to a better framework that will make modules hopefully more compatibles. That being said, it's important to bare in mind that 2 modules may be incompatible until a third patch module make them compatible by overriding anything required to take both modules into account. This is a sad reality, but it's the way we do, so any feature to detect incompatibilities should let the door open to "re-compatibilization" using those "patch modules". But speaking about that: I take the opportunity to advocate so we could also specify module version dependencies in the __openerp__ meta file. Indeed it's quite common that non core modules should be fetched from very specific branches or versions to get something working. Today it's a big mess, look how we do for instance for the new Magentoerpconnect modules, dependency versions/branches are specified in plain text in the branch summary because the framework leaves us no choice: https://code.launchpad.net/~magentoerpconnect-core-editors/magentoerpconnect/futur-trunk Now, look in the bug tracker how many folks try but don't manage to install the right versions... Some may think: we don't need to make OpenERP easy to install because they want to promote SaaS offers and professional services. But I insist this is so bad today that in fact it's currently harming OpenERP SA business model itself. It's reaching a point where only may be half of the ~300 OpenERP partners at best are able to install a complex localizations such as ours or a complex module such as Magentoepconnect (and I don't talk here about making it working, I just talk about installing it). An other issue the community fragmentation and lack of collaboration due to the poor ability to discover and install he right modules. apps.openerp.com doesn't currently support module version dependencies. In fact IMHO nothing would be worse than OpenERP SA spend on implementing this and struggle to make a return on our back afterwards. There are plenty of module system that already spent men years into building working version aware package managers (pip, apt-get, bundler...) But of course, it would always be possible. Now, the soonest we are able to collect that versions + repository information, the better. So why not use the v7 release as an opportunity to introduce that meta information change? Tools may follow later, at least the apparition of tooling won't break any API of a stable OpenERP release, so tools are less urgent than the meta-information format. Regular OpenERP addons are self contained and don't care much about version dependencies. But, in the real world, as soon as you leave Belgium or France and need complex localization modules or want some sophisticated verticals, you need extra non official modules. And very often the good ones aren't monolithic and add a whole tree of dependent modules and repositories. To give you an idea, in the project I'm working today, 55 modules installed are authored by Akretion and come from around 10 different branches. And this one of the only one of the ~10 OpenERP "to be working" implementation in Brazil, so it means that outside of that kind of architecture, OpenERP has almost no reality today here (fortunately it's a transitional phase like we had in France back to 2009 though). What I propose would be to continue to support the "dependencies" keyworkd in the __openerp__ file of course. But in parallel and before deprecation, we could introduce some "dependencies2" like keyword that would be a dictionary of dictionaries (or array of dictionaries) instead of just an array (or just be able to interpret both formats). Then, instead of re-inventing he wheel, we could take example on how good package managers use to encode version and repository dependencies. Here is an example with Bundler: http://gembundler.com/git.html as you can see, they support both version + repository: gem "deep_merge", "1.0", :git => "git://github.com/peritor/deep_merge.git" or even branch + revision: :git => "git://github.com/rails/rails.git", :ref => "4aded" In fact, I would advocate to primarily focus on supporting branch + revision because this is an information that already exists in our branches. Then eventually we could start educating the community to start supporting version numbers too but today people don't really update their module versions. I would also suggest we support bzr + git branches at least. I mean at least as a meta-information. As I said, let's define the format and let the community develop the tooling: best tools will win (I suggest interfacing with existing package managers) and this won't cost a penny to OpenERP SA. What do you think? Could we introduce this for OpenERP 7 ? If yes, let's debate the details of the exact format and start working. BTW, the French Akretion squad and me could visit OpenERP SA in Belgium during the beginning of July, may be it's something we could work on? Thoughts? On Fri, May 25, 2012 at 4:28 AM, Olivier Dony <[email protected]> wrote: > On 05/22/2012 01:35 PM, Alexandre Fayolle wrote: > > I'm coding a module which is similar in purpose to product_margin but > > works with a very different flow, which makes it meaningless to have > > both modules installed at the same time on a given instance. Is there a > > way of forbidding the installation of one of the two modules if the > > other one is already there, such as the Conflicts: field in a Debian > > package? This would mean that I'm able to use some of the nicely named > > columns from product_margin in my module. > > There is no exclusion mechanism foreseen in the API yet, because it's > usually > better to make the modules properly orthogonal and compatible with each > other, > or explicitly dependent of each other. > For example if your module kind of supersedes product_margin, you could > make it > depend on it and reuse whatever columns you like, while > hiding/disabling/overriding the rest of the module. That makes perfect > sense in > terms of modularity and dependencies. > > Now, you could probably introduce a specific hack in your module that > raises an > error when the classes are loaded if the state of the product_margin > module is > not 'uninstalled'. This should prevent installing both modules on the same > database. But I would avoid this hack if possible. > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-expert-framework > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-expert-framework > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
