openerp-expert-framework team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

Hello,

just one word to say that I totally support Alexandre's suggestion.
Till now OpenERP had a totally funky deprecation process. Many things in v7
have been deprecated silently in some nightly wild commit without any
previous warning and things have been the same in the past.
If OpenERP really wants to hire a partner network who invest in OpenERP and
forward some profit to OpenERP SA, then they need to completely change that
deprecation process and make it up to the mark. IMHO, Alexandre's
suggestion certainly improves the situation greatly: else we would still be
forced to grep inconsistent deprecation warnings in the output log, nobody
would do it and release policy would keep funky and below what is expected
from something aiming at being a prominent ERP. Let's move the tooling
toward the industry standards, you can be sure that some developers will
see the benefit, start using it and educate the community further about
more productive/sustainable development practices.

Regards.


-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com



On Wed, Sep 19, 2012 at 4:50 AM, Alexandre Fayolle <
alexandre.fayolle@xxxxxxxxxxxxxx> wrote:

> On mar. 18 sept. 2012 19:00:33 CEST, Xavier Morel wrote:
> > On 2012-09-18, at 17:17 , Alexandre Fayolle wrote:
> >
> >> Hello,
> >>
> >> I wanted to bring to your attention the proposal I made in
> >> https://bugs.launchpad.net/openobject-server/+bug/1052392 and for which
> >> I proposed an implementation in
> >>
> https://code.launchpad.net/~c2c/openobject-server/trunk-deprecate-osv_osv
> >>
> >> This is about using python stdlib DeprecationWarning and warnings module
> >> to tag deprecated features, rather than just putting a comment in the
> >> source code where it will likely be missed by most developers.
> >
> > The problem of this approach is that most developers are no more likely
> to
> > notice them with these improvements (which I support anyway) considering:
> >
> > 1. OpenERP's launch scripts do not (as far as I know) allow manipulations
> >    of the warnings filter (although it might be possible to use the
> Python
> >    interpreter explicitly and the -W flag, I'm not aware of anybody who
> >    does that ever, let alone on a regular basis)
> > 2. From Python 2.7 onwards, DeprecationWarning is silenced by default
> > 3. I don't believe there's any support for logging.captureWarnings
> either,
> >   it only exists in Python 2.7 anyway and (I believe) respects the
> >    warnings filter which you can't set (as per 1.)
> >
> > With all that, I rather doubt adding deprecation warnings in the code
> > would do anything more than the equivalent comments.
>
> Well if you look at the merge proposals, you'll see that there is
> support to set this from the command line and that by default,
> DeprecationWarnings are logged, but they can also be written to stderr
> or ignored. It is a start, and I'll gladly change the way things are
> done in there if people request for enhancements.
>
> Indeed I used the warnings.captureWarnings function to achieve this,
> which won't work with python < 2.7. OpenERP 6.1 apparently changed the
> minimum required Python version to 2.6. If we want to keep it that way
> in 2.7 I can write the required code to emulate captureWarnings in 2.6.
> Note to OpenERP folks: could you clarify the minimum required Python
> version for the next release? I think this deserves a mention in the
> README file (cf.
> https://bugs.launchpad.net/openobject-server/+bug/1052783)
>
> The point in this behavior is that it allows to see what is deprecated
> in the runbot logs (e.g.
> http://runbot.openerp.com/c2c-trunk-deprecate-osv-osv-17452/logs/server.txt
> ).
> There could even be an additional filter saying if there are some
> deprecation warnings triggered by the test or not.
>
> Given all that, I think educated developers will be able to look for
> such warnings and fix them in their code. Everyone will benefit from
> this, as it will reduce breakage when deprecated features are removed
> altogether (and it lowers the risks of making people unhappy when the
> removal occurs). With the deprecation policy and a clear tagging of the
> warnings I talked about in the OP, it becomes possible run the test
> base with settings that will trigger exceptions (and thus break the
> tests) when some code uses a feature that is going to completely
> disappear in the next stable release, meaning that it is time to bite
> the bullet and finally fix this code, which is important for
> integrators who wish to keep a single code base for extensions who need
> to support several releases.
>
> This applies to both the framework itself (I'm thinking of the API
> revamp that was presented at the community days last spring) and to the
> certified addons.
>
> Best regards,
>
> --
> Alexandre Fayolle
> Chef de Projet
> Tel : + 33 (0)4 79 26 57 94
>
> Camptocamp France SAS
> Savoie Technolac, BP 352
> 73377 Le Bourget du Lac Cedex
> http://www.camptocamp.com
>
>
> _______________________________________________
> 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
>