Community mailing list archives
Re: Proposal to review the OCA contribution guidelinesby
I also be reluctant at the beginning about changing my code style, but now that I'm following the strict PEP8 80 cols limit for 3 months, I don't know how can I read other code that doesn't follow this convention. Once you know the "tricks" and having an editor that helps you in formatting PEP8-friendly (PyCharm do it very well, PyDev for Eclipse not too much), it's very easy to write PEP8 code, maintain it or even converting old code to new style (we are making at OCA full repositories PEP8 fix, and there is a couple of hours of work with autopep8 + manual line adjustments for each ~2K lines of code).
>>> Have you ever tried to run flake8 on your modules ?
I have and the 80 character limit is the most annoying one.
If I run flake8 on some of our modules I get a lot of E501 warnings, such as :
__openerp__.py:37:80: E501 line too long (82 > 79 characters)
Of course we can fix all these, but in some cases it makes code readability worse and it takes time, hence adds a barrier that should not be there in my opinion.
>>> Despite you seams to have an other opinion, most (if not all) of OCA members agreed on this
I have seen 16 positive votes on this where the global community of Odoo developers is probably > 1000 persons.
I also understand from the community days that there are about 200 OCA members.
My point is about barriers to contribution.
Our first priority is to get our V6 and V7 modules tested and adapted to run correctly on V8 as part of customer commitments.
Adding PEP8/FLAKE8 compliancy (with our without the 80 character limit), test scenarios, … is a second priority.
Since it takes time (and time = money) it’s a barrier to contribute and hence will slow down the number of OCA contributions.
This being said, we’ll port our V7 OCA modules to V8 and we’ll publish them also via the OCA.
Seen the extra barrier, the OCA publications will be slower and less complete than our ‘apps.odoo.com’ publications.
<img border=0 width=96 height=33 id="Picture_x0020_1" src="cid:image001.jpg@01CFB71B.86902F70" alt="cid:image002.jpg@01CE271A.FF53FB90">
From: Yannick Vaucher [mailto:firstname.lastname@example.org]
Sent: woensdag 13 augustus 2014 14:43
Subject: Re: Proposal to review the OCA contribution guidelines
"barriers" such as PEP8 are there to ease the maintainability of a module.
It's not difficult to follow such line of conduct flake8 helps a lot. And OCA members are there to tell the commiter what exactly they need to change.
I think that one of the aim of OCA is to improve module's quality. And to improve functional quality you also need a good code base as you will need to maintain your code for that.
PEP8 can detect unused variables and unused import in you code which can obfuscate your code. It can detect long lines which can wrap and break indentation readability or be cut on small screen or when having two source file side to side (for diff and merge conflict resolution for exemple) opened in your prefered IDE.
With travis on github, PEP8 is now automatically checked and this means all old modules will be slowly but surely become PEP8 compliant.
PEP8 gives strong guidances to have a better readable and maintanable code. Despite you seams to have an other opinion, most (if not all) of OCA members agreed on this.
Have you ever tried to run flake8 on your modules ?
On Wed, Aug 13, 2014 at 2:03 PM, Luc De Meyer <email@example.com> wrote:
Dear Odoo community members,
I have been following a number of mail threads recently and I think that we are navigating in the wrong direction.
I’ll make myself clear by rephrasing the OCA mission statement and an example of where it goes wrong.
The OCA mission (cf. http://odoo-community.org/ ):
“The Odoo Community Association, or OCA, is a nonprofit organization whose mission is to support the collaborative development of Odoo features and promote its widespread use.”
My understanding of ‘features’ is ‘functionality’.
Our focus should be on stimulating the community to contribute new functionality and to improve existing functionality.
Based upon a few mail threads, we are currently adding barriers to contribution in stead of stimulating it.
I’ll illustrate my point via the following thread: OCA/maintainer-quality-tools#46.
The OCA guideline is that new contributions should be PEP8 compliant.
This guideline adds an extra barrier to people who want to contribute modules.
Why should we reject modules that comply to the following criteria
- The module adds extra functionality
- The module is compliant with the coding practices of the EDITOR (not the OCA)
- The module is compatible with the standard modules from Odoo
We are adding modules on top of the Odoo suite of business applications. None of the modules from Odoo are PEP8 compliant.
The vast majority of the current OCA modules are not PEP8 compliant.
Since I am working with OpenERP/Odoo (5 years now) I have never seen an RFP nor a customer demand to deliver a PEP8 compliant solution.
Hence why should we add this extra barrier ?
I personally find it hard to motivate myself to restyle a module that is working fine for many years in order to make it PEP8 compliant (with the ‘punch card age’ line length limitation as the most extreme one since I don’t like to spend even a minute of my time in order to make code harder to read and maintain).
Luc De Meyer
Rusatiralaan 1, 1083 Brussel
Luc De Meyer