openerp-expert-framework team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

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 <odo@xxxxxxxxxxx> 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     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>